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. But anyway, let's move on. Acked-by: Heiko Carstens <hca@xxxxxxxxxxxxx> However, I would like to see an Ack or review from Alexander Gordeev or Vasily Gorbik for this patch.
