Re: [PATCH v3 3/7] s390/physmem_info: query diag500(STORAGE LIMIT) to support QEMU/KVM memory devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 30.10.24 10:23, Heiko Carstens wrote:
On Fri, Oct 25, 2024 at 04:14:48PM +0200, David Hildenbrand wrote:
To support memory devices under QEMU/KVM, such as virtio-mem,
we have to prepare our kernel virtual address space accordingly and
have to know the highest possible physical memory address we might see
later: the storage limit. The good old SCLP interface is not suitable for
this use case.

In particular, memory owned by memory devices has no relationship to
storage increments, it is always detected using the device driver, and
unaware OSes (no driver) must never try making use of that memory.
Consequently this memory is located outside of the "maximum storage
increment"-indicated memory range.

Let's use our new diag500 STORAGE_LIMIT subcode to query this storage
limit that can exceed the "maximum storage increment", and use the
existing interfaces (i.e., SCLP) to obtain information about the initial
memory that is not owned+managed by memory devices.

If a hypervisor does not support such memory devices, the address exposed
through diag500 STORAGE_LIMIT will correspond to the maximum storage
increment exposed through SCLP.

To teach kdump on s390 to include memory owned by memory devices, there
will be ways to query the relevant memory ranges from the device via a
driver running in special kdump mode (like virtio-mem already implements
to filter /proc/vmcore access so we don't end up reading from unplugged
device blocks).

Update setup_ident_map_size(), to clarify that there can be more than
just online and standby memory.

Tested-by: Mario Casquero <mcasquer@xxxxxxxxxx>
Signed-off-by: David Hildenbrand <david@xxxxxxxxxx>
---
  arch/s390/boot/physmem_info.c        | 47 +++++++++++++++++++++++++++-
  arch/s390/boot/startup.c             |  7 +++--
  arch/s390/include/asm/physmem_info.h |  3 ++
  3 files changed, 54 insertions(+), 3 deletions(-)

Looks like I couldn't convince you to implement a query subcode.

Well, you convinced me that it might be useful, but after waiting on feedback from the KVM folks ... which didn't happen I moved on. In the cover letter I have "No query function for diag500 for now."

My thinking was that if we go for a query subcode, maybe we'd start "anew" with a new diag and use "0=query" like all similar instructions I am aware of. And that is then a bigger rework ...

... and I am not particularly interested in extra work without a clear statement from KVM people what (a) if that work is required and; (b) what it should look like.

Thanks for the review Heiko!

--
Cheers,

David / dhildenb





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Kernel Development]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Info]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Linux Media]     [Device Mapper]

  Powered by Linux