2019-05-19 15:07:45 +03:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
2007-10-22 05:03:36 +04:00
|
|
|
config VIRTIO
|
2008-02-05 07:50:05 +03:00
|
|
|
tristate
|
2020-06-13 19:50:22 +03:00
|
|
|
help
|
2012-09-28 09:35:15 +04:00
|
|
|
This option is selected by any driver which implements the virtio
|
2017-08-16 20:31:57 +03:00
|
|
|
bus, such as CONFIG_VIRTIO_PCI, CONFIG_VIRTIO_MMIO, CONFIG_RPMSG
|
|
|
|
|
or CONFIG_S390_GUEST.
|
2007-10-22 05:03:40 +04:00
|
|
|
|
2018-01-07 14:33:56 +03:00
|
|
|
menuconfig VIRTIO_MENU
|
|
|
|
|
bool "Virtio drivers"
|
|
|
|
|
default y
|
|
|
|
|
|
|
|
|
|
if VIRTIO_MENU
|
2011-07-05 18:06:14 +04:00
|
|
|
|
2007-11-13 06:30:26 +03:00
|
|
|
config VIRTIO_PCI
|
2012-10-02 22:19:07 +04:00
|
|
|
tristate "PCI driver for virtio devices"
|
|
|
|
|
depends on PCI
|
2007-11-13 06:30:26 +03:00
|
|
|
select VIRTIO
|
2020-06-13 19:50:22 +03:00
|
|
|
help
|
2015-01-15 15:15:51 +03:00
|
|
|
This driver provides support for virtio based paravirtual device
|
2007-11-13 06:30:26 +03:00
|
|
|
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.
|
|
|
|
|
|
2015-01-15 17:06:26 +03:00
|
|
|
config VIRTIO_PCI_LEGACY
|
|
|
|
|
bool "Support for legacy virtio draft 0.9.X and older devices"
|
|
|
|
|
default y
|
|
|
|
|
depends on VIRTIO_PCI
|
2020-06-13 19:50:22 +03:00
|
|
|
help
|
2015-01-15 17:06:26 +03:00
|
|
|
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.
|
|
|
|
|
|
2020-03-26 17:01:22 +03:00
|
|
|
config VIRTIO_VDPA
|
|
|
|
|
tristate "vDPA driver for virtio devices"
|
2020-04-12 11:36:55 +03:00
|
|
|
depends on VDPA
|
2020-03-26 17:01:22 +03:00
|
|
|
select VIRTIO
|
|
|
|
|
help
|
|
|
|
|
This driver provides support for virtio based paravirtual
|
|
|
|
|
device driver over vDPA bus. For this to be useful, you need
|
|
|
|
|
an appropriate vDPA device implementation that operates on a
|
|
|
|
|
physical device to allow the datapath of virtio to be
|
|
|
|
|
offloaded to hardware.
|
|
|
|
|
|
|
|
|
|
If unsure, say M.
|
|
|
|
|
|
2019-07-05 17:03:23 +03:00
|
|
|
config VIRTIO_PMEM
|
|
|
|
|
tristate "Support for virtio pmem driver"
|
|
|
|
|
depends on VIRTIO
|
|
|
|
|
depends on LIBNVDIMM
|
|
|
|
|
help
|
|
|
|
|
This driver provides access to virtio-pmem devices, storage devices
|
|
|
|
|
that are mapped into the physical address space - similar to NVDIMMs
|
|
|
|
|
- with a virtio-based flushing interface.
|
|
|
|
|
|
|
|
|
|
If unsure, say Y.
|
|
|
|
|
|
2008-02-05 07:50:12 +03:00
|
|
|
config VIRTIO_BALLOON
|
2012-09-28 09:35:14 +04:00
|
|
|
tristate "Virtio balloon driver"
|
|
|
|
|
depends on VIRTIO
|
2014-10-10 02:29:32 +04:00
|
|
|
select MEMORY_BALLOON
|
2020-04-07 06:05:05 +03:00
|
|
|
select PAGE_REPORTING
|
2020-06-13 19:50:22 +03:00
|
|
|
help
|
2008-02-05 07:50:12 +03:00
|
|
|
This driver supports increasing and decreasing the amount
|
|
|
|
|
of memory within a KVM guest.
|
|
|
|
|
|
|
|
|
|
If unsure, say M.
|
|
|
|
|
|
virtio-mem: Paravirtualized memory hotplug
Each virtio-mem device owns exactly one memory region. It is responsible
for adding/removing memory from that memory region on request.
When the device driver starts up, the requested amount of memory is
queried and then plugged to Linux. On request, further memory can be
plugged or unplugged. This patch only implements the plugging part.
On x86-64, memory can currently be plugged in 4MB ("subblock") granularity.
When required, a new memory block will be added (e.g., usually 128MB on
x86-64) in order to plug more subblocks. Only x86-64 was tested for now.
The online_page callback is used to keep unplugged subblocks offline
when onlining memory - similar to the Hyper-V balloon driver. Unplugged
pages are marked PG_offline, to tell dump tools (e.g., makedumpfile) to
skip them.
User space is usually responsible for onlining the added memory. The
memory hotplug notifier is used to synchronize virtio-mem activity
against memory onlining/offlining.
Each virtio-mem device can belong to a NUMA node, which allows us to
easily add/remove small chunks of memory to/from a specific NUMA node by
using multiple virtio-mem devices. Something that works even when the
guest has no idea about the NUMA topology.
One way to view virtio-mem is as a "resizable DIMM" or a DIMM with many
"sub-DIMMS".
This patch directly introduces the basic infrastructure to implement memory
unplug. Especially the memory block states and subblock bitmaps will be
heavily used there.
Notes:
- In case memory is to be onlined by user space, we limit the amount of
offline memory blocks, to not run out of memory. This is esp. an
issue if memory is added faster than it is getting onlined.
- Suspend/Hibernate is not supported due to the way virtio-mem devices
behave. Limited support might be possible in the future.
- Reloading the device driver is not supported.
Reviewed-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Tested-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: linux-acpi@vger.kernel.org
Signed-off-by: David Hildenbrand <david@redhat.com>
Link: https://lore.kernel.org/r/20200507140139.17083-2-david@redhat.com
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-05-07 17:01:25 +03:00
|
|
|
config VIRTIO_MEM
|
|
|
|
|
tristate "Virtio mem driver"
|
|
|
|
|
default m
|
|
|
|
|
depends on X86_64
|
|
|
|
|
depends on VIRTIO
|
|
|
|
|
depends on MEMORY_HOTPLUG_SPARSE
|
|
|
|
|
depends on MEMORY_HOTREMOVE
|
virtio-mem: Paravirtualized memory hotunplug part 2
We also want to unplug online memory (contained in online memory blocks
and, therefore, managed by the buddy), and eventually replug it later.
When requested to unplug memory, we use alloc_contig_range() to allocate
subblocks in online memory blocks (so we are the owner) and send them to
our hypervisor. When requested to plug memory, we can replug such memory
using free_contig_range() after asking our hypervisor.
We also want to mark all allocated pages PG_offline, so nobody will
touch them. To differentiate pages that were never onlined when
onlining the memory block from pages allocated via alloc_contig_range(), we
use PageDirty(). Based on this flag, virtio_mem_fake_online() can either
online the pages for the first time or use free_contig_range().
It is worth noting that there are no guarantees on how much memory can
actually get unplugged again. All device memory might completely be
fragmented with unmovable data, such that no subblock can get unplugged.
We are not touching the ZONE_MOVABLE. If memory is onlined to the
ZONE_MOVABLE, it can only get unplugged after that memory was offlined
manually by user space. In normal operation, virtio-mem memory is
suggested to be onlined to ZONE_NORMAL. In the future, we will try to
make unplug more likely to succeed.
Add a module parameter to control if online memory shall be touched.
As we want to access alloc_contig_range()/free_contig_range() from
kernel module context, export the symbols.
Note: Whenever virtio-mem uses alloc_contig_range(), all affected pages
are on the same node, in the same zone, and contain no holes.
Acked-by: Michal Hocko <mhocko@suse.com> # to export contig range allocator API
Tested-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Cc: Alexander Potapenko <glider@google.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Link: https://lore.kernel.org/r/20200507140139.17083-6-david@redhat.com
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-05-07 17:01:29 +03:00
|
|
|
select CONTIG_ALLOC
|
virtio-mem: Paravirtualized memory hotplug
Each virtio-mem device owns exactly one memory region. It is responsible
for adding/removing memory from that memory region on request.
When the device driver starts up, the requested amount of memory is
queried and then plugged to Linux. On request, further memory can be
plugged or unplugged. This patch only implements the plugging part.
On x86-64, memory can currently be plugged in 4MB ("subblock") granularity.
When required, a new memory block will be added (e.g., usually 128MB on
x86-64) in order to plug more subblocks. Only x86-64 was tested for now.
The online_page callback is used to keep unplugged subblocks offline
when onlining memory - similar to the Hyper-V balloon driver. Unplugged
pages are marked PG_offline, to tell dump tools (e.g., makedumpfile) to
skip them.
User space is usually responsible for onlining the added memory. The
memory hotplug notifier is used to synchronize virtio-mem activity
against memory onlining/offlining.
Each virtio-mem device can belong to a NUMA node, which allows us to
easily add/remove small chunks of memory to/from a specific NUMA node by
using multiple virtio-mem devices. Something that works even when the
guest has no idea about the NUMA topology.
One way to view virtio-mem is as a "resizable DIMM" or a DIMM with many
"sub-DIMMS".
This patch directly introduces the basic infrastructure to implement memory
unplug. Especially the memory block states and subblock bitmaps will be
heavily used there.
Notes:
- In case memory is to be onlined by user space, we limit the amount of
offline memory blocks, to not run out of memory. This is esp. an
issue if memory is added faster than it is getting onlined.
- Suspend/Hibernate is not supported due to the way virtio-mem devices
behave. Limited support might be possible in the future.
- Reloading the device driver is not supported.
Reviewed-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Tested-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: linux-acpi@vger.kernel.org
Signed-off-by: David Hildenbrand <david@redhat.com>
Link: https://lore.kernel.org/r/20200507140139.17083-2-david@redhat.com
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-05-07 17:01:25 +03:00
|
|
|
help
|
|
|
|
|
This driver provides access to virtio-mem paravirtualized memory
|
|
|
|
|
devices, allowing to hotplug and hotunplug memory.
|
|
|
|
|
|
|
|
|
|
This driver was only tested under x86-64, but should theoretically
|
|
|
|
|
work on all architectures that support memory hotplug and hotremove.
|
|
|
|
|
|
|
|
|
|
If unsure, say M.
|
|
|
|
|
|
2015-03-27 05:16:12 +03:00
|
|
|
config VIRTIO_INPUT
|
|
|
|
|
tristate "Virtio input driver"
|
|
|
|
|
depends on VIRTIO
|
|
|
|
|
depends on INPUT
|
2020-06-13 19:50:22 +03:00
|
|
|
help
|
2015-03-27 05:16:12 +03:00
|
|
|
This driver supports virtio input devices such as
|
|
|
|
|
keyboards, mice and tablets.
|
|
|
|
|
|
|
|
|
|
If unsure, say M.
|
|
|
|
|
|
2019-04-03 18:04:09 +03:00
|
|
|
config VIRTIO_MMIO
|
2012-10-02 22:19:07 +04:00
|
|
|
tristate "Platform bus driver for memory mapped virtio devices"
|
2016-02-03 08:46:36 +03:00
|
|
|
depends on HAS_IOMEM && HAS_DMA
|
2019-04-03 18:04:09 +03:00
|
|
|
select VIRTIO
|
2020-06-13 19:50:22 +03:00
|
|
|
help
|
2019-04-03 18:04:09 +03:00
|
|
|
This drivers provides support for memory mapped virtio
|
2011-10-24 17:07:03 +04:00
|
|
|
platform device driver.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2012-05-09 21:30:16 +04:00
|
|
|
config VIRTIO_MMIO_CMDLINE_DEVICES
|
|
|
|
|
bool "Memory mapped virtio devices parameter parsing"
|
|
|
|
|
depends on VIRTIO_MMIO
|
2020-06-13 19:50:22 +03:00
|
|
|
help
|
2012-05-09 21:30:16 +04:00
|
|
|
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.
|
2016-10-18 15:12:27 +03:00
|
|
|
See Documentation/admin-guide/kernel-parameters.rst for details.
|
2012-05-09 21:30:16 +04:00
|
|
|
|
|
|
|
|
If unsure, say 'N'.
|
|
|
|
|
|
2018-01-07 14:33:56 +03:00
|
|
|
endif # VIRTIO_MENU
|
