mbox series

[v1,0/5] virtio-mem: s390x support

Message ID 20240910191541.2179655-1-david@redhat.com (mailing list archive)
Headers show
Series virtio-mem: s390x support | expand

Message

David Hildenbrand Sept. 10, 2024, 7:15 p.m. UTC
Let's finally add s390x support for virtio-mem; my last RFC was sent
4 years ago, and a lot changed in the meantime.

This is based on mm/stable.

I sent out the QEMU part earlier today [1], that contains some more details
and a usage example on s390x (last patch).

There is not too much in here: The biggest part is querying a new diag(500)
STORAGE_LIMIT hypercall to obtain the proper "max_physmem_end". Once this
and the QEMU part will go upstream, it will get documented in [2]

The last two patches are not strictly required but certainly nice-to-have.

Note that -- in contrast to standby memory -- virtio-mem memory must be
configured to be automatically onlined as soon as hotplugged. The easiest
approach is using the "memhp_default_state=" kernel parameter or by using
proper udev rules. More details can be found at [3].

I have reviving+upstreaming a systemd service to handle configuring
that on my todo list, but for some reason I keep getting distracted ...

I tested various things, including:
 * Various memory hotplug/hotunplug combinations
 * Device hotplug/hotunplug
 * /proc/iomem output
 * reboot
 * kexec
 * kdump: make sure we don't hotplug memory

One remaining work item is kdump support for virtio-mem memory. I
am working on a prototype that will be fairly straight forward,
because the virtio-mem driver already supports a special kdump mode and
dracut will already include it in the initrd as default. With
holiday and conferences coming up I rather sent this out now.

[1] https://lkml.kernel.org/r/20240910175809.2135596-1-david@redhat.com
[2] https://gitlab.com/davidhildenbrand/s390x-os-virt-spec
[3] https://virtio-mem.gitlab.io/user-guide/user-guide-linux.html

Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
Cc: Sven Schnelle <svens@linux.ibm.com>
Cc: Thomas Huth <thuth@redhat.com>
Cc: Cornelia Huck <cohuck@redhat.com>
Cc: Janosch Frank <frankja@linux.ibm.com>
Cc: Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Cc: "Eugenio Pérez" <eperezma@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>

David Hildenbrand (5):
  s390/kdump: implement is_kdump_kernel()
  s390/physmem_info: query diag500(STORAGE_LIMIT) to support QEMU/KVM
    memory devices
  virtio-mem: s390x support
  lib/Kconfig.debug: default STRICT_DEVMEM to "y" on s390x
  s390/sparsemem: reduce section size to 128 MiB

 arch/s390/boot/physmem_info.c        | 46 ++++++++++++++++++++++++++--
 arch/s390/include/asm/kexec.h        |  4 +++
 arch/s390/include/asm/physmem_info.h |  3 ++
 arch/s390/include/asm/sparsemem.h    |  2 +-
 arch/s390/kernel/crash_dump.c        |  6 ++++
 drivers/virtio/Kconfig               | 12 ++++----
 lib/Kconfig.debug                    |  2 +-
 7 files changed, 64 insertions(+), 11 deletions(-)

Comments

Michael S. Tsirkin Sept. 10, 2024, 8:19 p.m. UTC | #1
On Tue, Sep 10, 2024 at 09:15:34PM +0200, David Hildenbrand wrote:
> Let's finally add s390x support for virtio-mem; my last RFC was sent
> 4 years ago, and a lot changed in the meantime.
> 
> This is based on mm/stable.
> 
> I sent out the QEMU part earlier today [1], that contains some more details
> and a usage example on s390x (last patch).
> 
> There is not too much in here: The biggest part is querying a new diag(500)
> STORAGE_LIMIT hypercall to obtain the proper "max_physmem_end". Once this
> and the QEMU part will go upstream, it will get documented in [2]
> 
> The last two patches are not strictly required but certainly nice-to-have.
> 
> Note that -- in contrast to standby memory -- virtio-mem memory must be
> configured to be automatically onlined as soon as hotplugged. The easiest
> approach is using the "memhp_default_state=" kernel parameter or by using
> proper udev rules. More details can be found at [3].
> 
> I have reviving+upstreaming a systemd service to handle configuring
> that on my todo list, but for some reason I keep getting distracted ...
> 
> I tested various things, including:
>  * Various memory hotplug/hotunplug combinations
>  * Device hotplug/hotunplug
>  * /proc/iomem output
>  * reboot
>  * kexec
>  * kdump: make sure we don't hotplug memory
> 
> One remaining work item is kdump support for virtio-mem memory. I
> am working on a prototype that will be fairly straight forward,
> because the virtio-mem driver already supports a special kdump mode and
> dracut will already include it in the initrd as default. With
> holiday and conferences coming up I rather sent this out now.
> 
> [1] https://lkml.kernel.org/r/20240910175809.2135596-1-david@redhat.com
> [2] https://gitlab.com/davidhildenbrand/s390x-os-virt-spec
> [3] https://virtio-mem.gitlab.io/user-guide/user-guide-linux.html
> 
> Cc: Heiko Carstens <hca@linux.ibm.com>
> Cc: Vasily Gorbik <gor@linux.ibm.com>
> Cc: Alexander Gordeev <agordeev@linux.ibm.com>
> Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
> Cc: Sven Schnelle <svens@linux.ibm.com>
> Cc: Thomas Huth <thuth@redhat.com>
> Cc: Cornelia Huck <cohuck@redhat.com>
> Cc: Janosch Frank <frankja@linux.ibm.com>
> Cc: Claudio Imbrenda <imbrenda@linux.ibm.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: Jason Wang <jasowang@redhat.com>
> Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> Cc: "Eugenio Pérez" <eperezma@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>


It's mostly s390 changes, so should be merged through that tree.
I acked the only virtio specific patch.

> David Hildenbrand (5):
>   s390/kdump: implement is_kdump_kernel()
>   s390/physmem_info: query diag500(STORAGE_LIMIT) to support QEMU/KVM
>     memory devices
>   virtio-mem: s390x support
>   lib/Kconfig.debug: default STRICT_DEVMEM to "y" on s390x
>   s390/sparsemem: reduce section size to 128 MiB
> 
>  arch/s390/boot/physmem_info.c        | 46 ++++++++++++++++++++++++++--
>  arch/s390/include/asm/kexec.h        |  4 +++
>  arch/s390/include/asm/physmem_info.h |  3 ++
>  arch/s390/include/asm/sparsemem.h    |  2 +-
>  arch/s390/kernel/crash_dump.c        |  6 ++++
>  drivers/virtio/Kconfig               | 12 ++++----
>  lib/Kconfig.debug                    |  2 +-
>  7 files changed, 64 insertions(+), 11 deletions(-)
> 
> -- 
> 2.46.0
Mario Casquero Oct. 10, 2024, 8:41 a.m. UTC | #2
This series has been successfully tested along with the QEMU's series.
Virtio-mem devices could be resized, plugged and unplugged seamlessly.
The memory information displayed is correct and reboot doesn't cause
any issue.

Tested-by: Mario Casquero <mcasquer@redhat.com>

On Tue, Sep 10, 2024 at 9:16 PM David Hildenbrand <david@redhat.com> wrote:
>
> Let's finally add s390x support for virtio-mem; my last RFC was sent
> 4 years ago, and a lot changed in the meantime.
>
> This is based on mm/stable.
>
> I sent out the QEMU part earlier today [1], that contains some more details
> and a usage example on s390x (last patch).
>
> There is not too much in here: The biggest part is querying a new diag(500)
> STORAGE_LIMIT hypercall to obtain the proper "max_physmem_end". Once this
> and the QEMU part will go upstream, it will get documented in [2]
>
> The last two patches are not strictly required but certainly nice-to-have.
>
> Note that -- in contrast to standby memory -- virtio-mem memory must be
> configured to be automatically onlined as soon as hotplugged. The easiest
> approach is using the "memhp_default_state=" kernel parameter or by using
> proper udev rules. More details can be found at [3].
>
> I have reviving+upstreaming a systemd service to handle configuring
> that on my todo list, but for some reason I keep getting distracted ...
>
> I tested various things, including:
>  * Various memory hotplug/hotunplug combinations
>  * Device hotplug/hotunplug
>  * /proc/iomem output
>  * reboot
>  * kexec
>  * kdump: make sure we don't hotplug memory
>
> One remaining work item is kdump support for virtio-mem memory. I
> am working on a prototype that will be fairly straight forward,
> because the virtio-mem driver already supports a special kdump mode and
> dracut will already include it in the initrd as default. With
> holiday and conferences coming up I rather sent this out now.
>
> [1] https://lkml.kernel.org/r/20240910175809.2135596-1-david@redhat.com
> [2] https://gitlab.com/davidhildenbrand/s390x-os-virt-spec
> [3] https://virtio-mem.gitlab.io/user-guide/user-guide-linux.html
>
> Cc: Heiko Carstens <hca@linux.ibm.com>
> Cc: Vasily Gorbik <gor@linux.ibm.com>
> Cc: Alexander Gordeev <agordeev@linux.ibm.com>
> Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
> Cc: Sven Schnelle <svens@linux.ibm.com>
> Cc: Thomas Huth <thuth@redhat.com>
> Cc: Cornelia Huck <cohuck@redhat.com>
> Cc: Janosch Frank <frankja@linux.ibm.com>
> Cc: Claudio Imbrenda <imbrenda@linux.ibm.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: Jason Wang <jasowang@redhat.com>
> Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> Cc: "Eugenio Pérez" <eperezma@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
>
> David Hildenbrand (5):
>   s390/kdump: implement is_kdump_kernel()
>   s390/physmem_info: query diag500(STORAGE_LIMIT) to support QEMU/KVM
>     memory devices
>   virtio-mem: s390x support
>   lib/Kconfig.debug: default STRICT_DEVMEM to "y" on s390x
>   s390/sparsemem: reduce section size to 128 MiB
>
>  arch/s390/boot/physmem_info.c        | 46 ++++++++++++++++++++++++++--
>  arch/s390/include/asm/kexec.h        |  4 +++
>  arch/s390/include/asm/physmem_info.h |  3 ++
>  arch/s390/include/asm/sparsemem.h    |  2 +-
>  arch/s390/kernel/crash_dump.c        |  6 ++++
>  drivers/virtio/Kconfig               | 12 ++++----
>  lib/Kconfig.debug                    |  2 +-
>  7 files changed, 64 insertions(+), 11 deletions(-)
>
> --
> 2.46.0
>
>
David Hildenbrand Oct. 10, 2024, 12:31 p.m. UTC | #3
On 10.10.24 10:41, Mario Casquero wrote:
> This series has been successfully tested along with the QEMU's series.
> Virtio-mem devices could be resized, plugged and unplugged seamlessly.
> The memory information displayed is correct and reboot doesn't cause
> any issue.
> 
> Tested-by: Mario Casquero <mcasquer@redhat.com>

Thanks a bunch for testing!

If there are no more comments, I'll add the in-tree kernel update for 
the new diag500 subcall and resend.
Heiko Carstens Oct. 10, 2024, 2:41 p.m. UTC | #4
On Thu, Oct 10, 2024 at 02:31:31PM +0200, David Hildenbrand wrote:
> On 10.10.24 10:41, Mario Casquero wrote:
> > This series has been successfully tested along with the QEMU's series.
> > Virtio-mem devices could be resized, plugged and unplugged seamlessly.
> > The memory information displayed is correct and reboot doesn't cause
> > any issue.
> > 
> > Tested-by: Mario Casquero <mcasquer@redhat.com>
> 
> Thanks a bunch for testing!
> 
> If there are no more comments, I'll add the in-tree kernel update for the
> new diag500 subcall and resend.

Sorry that you haven't seen any review from here yet, but... :)

Please also change all usages of "s390x" to "s390" before you resend.
Within the kernel usage of s390x is not common and there shouldn't be
anything like this added.
David Hildenbrand Oct. 10, 2024, 2:42 p.m. UTC | #5
On 10.10.24 16:41, Heiko Carstens wrote:
> On Thu, Oct 10, 2024 at 02:31:31PM +0200, David Hildenbrand wrote:
>> On 10.10.24 10:41, Mario Casquero wrote:
>>> This series has been successfully tested along with the QEMU's series.
>>> Virtio-mem devices could be resized, plugged and unplugged seamlessly.
>>> The memory information displayed is correct and reboot doesn't cause
>>> any issue.
>>>
>>> Tested-by: Mario Casquero <mcasquer@redhat.com>
>>
>> Thanks a bunch for testing!
>>
>> If there are no more comments, I'll add the in-tree kernel update for the
>> new diag500 subcall and resend.
> 
> Sorry that you haven't seen any review from here yet, but... :)
> 
> Please also change all usages of "s390x" to "s390" before you resend.
> Within the kernel usage of s390x is not common and there shouldn't be
> anything like this added.

Makes sense, thanks!