linux-next/drivers/virtio/Kconfig
David Hildenbrand 38968bcdcc virtio-mem: s390 support
Now that s390 code is prepared for memory devices that reside above the
maximum storage increment exposed through SCLP, everything is in place
to unlock virtio-mem support.

As virtio-mem in Linux currently supports logically onlining/offlining
memory in pageblock granularity, we have an effective hot(un)plug
granularity of 1 MiB on s390.

As virito-mem adds/removes individual Linux memory blocks (256MB), we
will currently never use gigantic pages in the identity mapping.

It is worth noting that neither storage keys nor storage attributes (e.g.,
data / nodat) are touched when onlining memory blocks, which is good
because we are not supposed to touch these parts for unplugged device
blocks that are logically offline in Linux.

We will currently never initialize storage keys for virtio-mem
memory -- IOW, storage_key_init_range() is never called. It could be added
in the future when plugging device blocks. But as that function
essentially does nothing without modifying the code (changing
PAGE_DEFAULT_ACC), that's just fine for now.

kexec should work as intended and just like on other architectures that
support virtio-mem: we will never place kexec binaries on virtio-mem
memory, and never indicate virtio-mem memory to the 2nd kernel. The
device driver in the 2nd kernel can simply reset the device --
turning all memory unplugged, to then start plugging memory and adding
them to Linux, without causing trouble because the memory is already
used elsewhere.

The special s390 kdump mode, whereby the 2nd kernel creates the ELF
core header, won't currently dump virtio-mem memory. The virtio-mem
driver has a special kdump mode, from where we can detect memory ranges
to dump. Based on this, support for dumping virtio-mem memory can be
added in the future fairly easily.

Acked-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Mario Casquero <mcasquer@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Tested-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Link: https://lore.kernel.org/r/20241025141453.1210600-5-david@redhat.com
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-11-07 10:26:24 +01:00

192 lines
5.5 KiB
Plaintext

# SPDX-License-Identifier: GPL-2.0-only
config VIRTIO_ANCHOR
bool
config VIRTIO
tristate
select VIRTIO_ANCHOR
help
This option is selected by any driver which implements the virtio
bus, such as CONFIG_VIRTIO_PCI, CONFIG_VIRTIO_MMIO, CONFIG_RPMSG
or CONFIG_S390_GUEST.
config VIRTIO_PCI_LIB
tristate
help
Modern PCI device implementation. This module implements the
basic probe and control for devices which are based on modern
PCI device with possible vendor specific extensions. Any
module that selects this module must depend on PCI.
config VIRTIO_PCI_LIB_LEGACY
tristate
help
Legacy PCI device (Virtio PCI Card 0.9.x Draft and older device)
implementation.
This module implements the basic probe and control for devices
which are based on legacy PCI device. Any module that selects this
module must depend on PCI.
menuconfig VIRTIO_MENU
bool "Virtio drivers"
default y
if VIRTIO_MENU
config VIRTIO_HARDEN_NOTIFICATION
bool "Harden virtio notification"
depends on BROKEN
help
Enable this to harden the device notifications and suppress
those that happen at a time where notifications are illegal.
Experimental: Note that several drivers still have issues that
may cause crashes or hangs when correct handling of
notifications is enforced; depending on the subset of
drivers and devices you use, this may or may not work.
If unsure, say N.
config VIRTIO_PCI
tristate "PCI driver for virtio devices"
depends on PCI
select VIRTIO_PCI_LIB
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_ADMIN_LEGACY
bool
depends on VIRTIO_PCI && (X86 || COMPILE_TEST)
default y
config VIRTIO_PCI_LEGACY
bool "Support for legacy virtio draft 0.9.X and older devices"
default y
depends on VIRTIO_PCI
select VIRTIO_PCI_LIB_LEGACY
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_VDPA
tristate "vDPA driver for virtio devices"
depends on VDPA
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.
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.
config VIRTIO_BALLOON
tristate "Virtio balloon driver"
depends on VIRTIO
select MEMORY_BALLOON
select PAGE_REPORTING
help
This driver supports increasing and decreasing the amount
of memory within a KVM guest.
If unsure, say M.
config VIRTIO_MEM
tristate "Virtio mem driver"
depends on X86_64 || ARM64 || RISCV || S390
depends on VIRTIO
depends on MEMORY_HOTPLUG
depends on MEMORY_HOTREMOVE
depends on CONTIG_ALLOC
depends on EXCLUSIVE_SYSTEM_RAM
help
This driver provides access to virtio-mem paravirtualized memory
devices, allowing to hotplug and hotunplug memory.
This driver currently supports x86-64, arm64, riscv and s390.
Although it should compile on other architectures that implement
memory hot(un)plug, architecture-specific and/or common
code changes may be required for virtio-mem, kdump and kexec to
work as expected.
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'.
config VIRTIO_DMA_SHARED_BUFFER
tristate
depends on DMA_SHARED_BUFFER
help
This option adds a flavor of dma buffers that are backed by
virtio resources.
config VIRTIO_DEBUG
bool "Debug facilities"
depends on VIRTIO
help
Enable this to expose debug facilities over debugfs.
This allows to debug features, to see what features the device
advertises and to set filter for features used by driver.
If unsure, say N.
endif # VIRTIO_MENU