| Message ID | 20240910191541.2179655-4-david@redhat.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | virtio-mem: s390x support | expand |
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@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> > --- > 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
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.
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@redhat.com> --- drivers/virtio/Kconfig | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)