Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux

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>

authored by

David Hildenbrand and committed by
Heiko Carstens
38968bcd 63938e17

+6 -6
+6 -6
drivers/virtio/Kconfig
··· 122 122 123 123 config VIRTIO_MEM 124 124 tristate "Virtio mem driver" 125 - depends on X86_64 || ARM64 || RISCV 125 + depends on X86_64 || ARM64 || RISCV || S390 126 126 depends on VIRTIO 127 127 depends on MEMORY_HOTPLUG 128 128 depends on MEMORY_HOTREMOVE ··· 132 132 This driver provides access to virtio-mem paravirtualized memory 133 133 devices, allowing to hotplug and hotunplug memory. 134 134 135 - This driver currently only supports x86-64 and arm64. Although it 136 - should compile on other architectures that implement memory 137 - hot(un)plug, architecture-specific and/or common 138 - code changes may be required for virtio-mem, kdump and kexec to work as 139 - expected. 135 + This driver currently supports x86-64, arm64, riscv and s390. 136 + Although it should compile on other architectures that implement 137 + memory hot(un)plug, architecture-specific and/or common 138 + code changes may be required for virtio-mem, kdump and kexec to 139 + work as expected. 140 140 141 141 If unsure, say M. 142 142