config VIRTIO tristate ---help--- This option is selected by any driver which implements the virtio bus, such as CONFIG_VIRTIO_PCI, CONFIG_VIRTIO_MMIO, CONFIG_LGUEST, CONFIG_RPMSG or CONFIG_S390_GUEST. menu "Virtio drivers" config VIRTIO_PCI tristate "PCI driver for virtio devices" depends on PCI select VIRTIO ---help--- This driver provides support for virtio based paravirtual device drivers over PCI. This requires that your VMM has appropriate PCI virtio backends. Most QEMU based VMMs should support these devices (like KVM or Xen). If unsure, say M. config VIRTIO_PCI_LEGACY bool "Support for legacy virtio draft 0.9.X and older devices" default y depends on VIRTIO_PCI ---help--- Virtio PCI Card 0.9.X Draft (circa 2014) and older device support. This option enables building a transitional driver, supporting both devices conforming to Virtio 1 specification, and legacy devices. If disabled, you get a slightly smaller, non-transitional driver, with no legacy compatibility. So look out into your driveway. Do you have a flying car? If so, you can happily disable this option and virtio will not break. Otherwise, leave it set. Unless you're testing what life will be like in The Future. If unsure, say Y. config VIRTIO_BALLOON tristate "Virtio balloon driver" depends on VIRTIO select MEMORY_BALLOON ---help--- This driver supports increasing and decreasing the amount of memory within a KVM guest. If unsure, say M. config VIRTIO_INPUT tristate "Virtio input driver" depends on VIRTIO depends on INPUT ---help--- This driver supports virtio input devices such as keyboards, mice and tablets. If unsure, say M. config VIRTIO_MMIO tristate "Platform bus driver for memory mapped virtio devices" depends on HAS_IOMEM && HAS_DMA select VIRTIO ---help--- This drivers provides support for memory mapped virtio platform device driver. If unsure, say N. config VIRTIO_MMIO_CMDLINE_DEVICES bool "Memory mapped virtio devices parameter parsing" depends on VIRTIO_MMIO ---help--- Allow virtio-mmio devices instantiation via the kernel command line or module parameters. Be aware that using incorrect parameters (base address in particular) can crash your system - you have been warned. See Documentation/admin-guide/kernel-parameters.rst for details. If unsure, say 'N'. endmenu .h'>
path: root/include/drm/drm_cache.h
diff options
context:
space:
mode:
authorBenjamin Herrenschmidt <benh@kernel.crashing.org>2017-02-03 17:10:28 +1100
committerMichael Ellerman <mpe@ellerman.id.au>2017-02-08 23:36:29 +1100
commitd7df2443cd5f67fc6ee7c05a88e4996e8177f91b (patch)
tree098a7c0ca4fceb8a65cb1f693c9d71990388933d /include/drm/drm_cache.h
parenta0615a16f7d0ceb5804d295203c302d496d8ee91 (diff)
powerpc/mm: Fix spurrious segfaults on radix with autonuma
When autonuma (Automatic NUMA balancing) marks a PTE inaccessible it clears all the protection bits but leave the PTE valid. With the Radix MMU, an attempt at executing from such a PTE will take a fault with bit 35 of SRR1 set "SRR1_ISI_N_OR_G". It is thus incorrect to treat all such faults as errors. We should pass them to handle_mm_fault() for autonuma to deal with. The case of pages that are really not executable is handled by the existing test for VM_EXEC further down. That leaves us with catching the kernel attempts at executing user pages. We can catch that earlier, even before we do find_vma. It is never valid on powerpc for the kernel to take an exec fault to begin with. So fold that test with the existing test for the kernel faulting on kernel addresses to bail out early. Fixes: 1d18ad026844 ("powerpc/mm: Detect instruction fetch denied and report") Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Acked-by: Balbir Singh <bsingharora@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Diffstat (limited to 'include/drm/drm_cache.h')