qiurui
/
Centos-kernel-stream-9
mirror of https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

virtio-mem: s390 support 

JIRA: https://issues.redhat.com/browse/RHEL-72974

commit 38968bcdcc1d46f2fdcd3a72599d5193bf8baf84
Author: David Hildenbrand <david@redhat.com>
Date:   Fri Oct 25 16:14:49 2024 +0200

    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>

Conflicts:
    drivers/virtio/Kconfig
    (no RISCV support in downstream yet)
Signed-off-by: Thomas Huth <thuth@redhat.com>
This commit is contained in:
Thomas Huth 2025-04-04 14:40:14 +02:00
parent 0603259460
commit 91ee5e8dcc
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
drivers/virtio/Kconfig
View File

@ -103,7 +103,7 @@ config VIRTIO_BALLOON
config VIRTIO_MEM
tristate "Virtio mem driver"
depends on X86_64 || ARM64
depends on X86_64 || ARM64 || S390
depends on VIRTIO
depends on MEMORY_HOTPLUG
depends on MEMORY_HOTREMOVE
@ -113,11 +113,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 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.