Re: [PATCH RFC 2/5] s390x: implement diag260

From: Heiko Carstens <hca@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>
Cc: Thomas Huth <thuth@redhat.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	qemu-devel@nongnu.org, Halil Pasic <pasic@linux.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	qemu-s390x@nongnu.org, Claudio Imbrenda <imbrenda@linux.ibm.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH RFC 2/5] s390x: implement diag260
Date: Wed, 15 Jul 2020 12:43:48 +0200	[thread overview]
Message-ID: <20200715104348.GB6927@osiris> (raw)
In-Reply-To: <a0b52f65-d253-c51b-6dfc-0a61f939c759@redhat.com>

On Wed, Jul 15, 2020 at 11:42:37AM +0200, David Hildenbrand wrote:
> So, in summary, we want to indicate to the guest a memory region that
> will be used to place memory devices ("device memory region"). The
> region might have holes and the memory within this region might have
> different semantics than ordinary system memory. Memory that belongs to
> memory devices should only be detected+used if the guest OS has support
> for them (e.g., virtio-mem, virtio-pmem, ...). An unmodified guest
> (e.g., no virtio-mem driver) should not accidentally make use of such
> memory.
> 
> We need a way to
> a) Tell the guest about boot memory (currently ram_size)
> b) Tell the guest about the maximum possible ram address, including
> device memory. (We could also indicate the special "device memory
> region" explicitly)
> 
> AFAIK, we have three options:
> 
> 1. Indicate maxram_size via SCLP, indicate ram_size via diag260(0x10)
> 
> This is what this series (RFCv1 does).
> 
> Advantages:
> - No need for a new diag. No need for memory sensing kernel changes.
> Disadvantages
> - Older guests without support for diag260 (<v4.2, kvm-unit-tests) will
>   assume all memory is accessible. Bad.

Why would old guests assume that?

At least in v4.1 the kernel will calculate the max address by using
increment size * increment number and then test if *each* increment is
available with tprot.

> - The semantics of the value returned in ry via diag260(0xc) is somewhat
>   unclear. Should we return the end address of the highest memory
>   device? OTOH, an unmodified guest OS (without support for memory
>   devices) should not have to care at all about any such memory.

I'm confused. The kernel currently only uses diag260(0x10). How is
diag260(0xc) relevant here?

> 3. Indicate maxram_size and ram_size via SCLP (using the SCLP standby
>    memory)
> 
> I did not look into the details, because -ENODOCUMENTATION. At least we
> would run into some alignment issues (again, having to align
> ram_size/maxram_size to storage increments - which would no longer be
> 1MB). We would run into issues later, trying to also support standby memory.

That doesn't make sense to me: either support memory hotplug via
sclp/standby memory, or with your new method. But trying to support
both.. what's the use case?