On Tue, Sep 10, 2024 at 09:15:37PM +0200, David Hildenbrand wrote: > Now that s390x 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 s390x. > > 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 s390x 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. > > Signed-off-by: David Hildenbrand <david@xxxxxxxxxx> Acked-by: Michael S. Tsirkin <mst@xxxxxxxxxx> > --- > drivers/virtio/Kconfig | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig > index 42a48ac763ee..fb320eea70fe 100644 > --- a/drivers/virtio/Kconfig > +++ b/drivers/virtio/Kconfig > @@ -122,7 +122,7 @@ config VIRTIO_BALLOON > > config VIRTIO_MEM > tristate "Virtio mem driver" > - depends on X86_64 || ARM64 || RISCV > + depends on X86_64 || ARM64 || RISCV || S390 > depends on VIRTIO > depends on MEMORY_HOTPLUG > depends on MEMORY_HOTREMOVE > @@ -132,11 +132,11 @@ config VIRTIO_MEM > This driver provides access to virtio-mem paravirtualized memory > devices, allowing to hotplug and hotunplug memory. > > - This driver currently only supports x86-64 and arm64. 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. > + This driver currently supports x86-64, arm64, riscv and s390x. > + 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. > > -- > 2.46.0
