On 02/22/2018 06:13 AM, Christian Borntraeger wrote: > > > On 02/21/2018 06:39 PM, Cornelia Huck wrote: >> On Tue, 20 Feb 2018 16:05:54 +0100 >> David Hildenbrand <da...@redhat.com> wrote: >> >>> On 20.02.2018 15:57, Cornelia Huck wrote: >>>> On Tue, 20 Feb 2018 13:16:37 +0100 >>>> David Hildenbrand <da...@redhat.com> wrote: >>>> >>>>> On 20.02.2018 13:05, Christian Borntraeger wrote: >>>>>> >>>>>> >>>>>> On 02/19/2018 06:42 PM, David Hildenbrand wrote: >>>>>>> From an architecture point of view, nothing can be mapped into the >>>>>>> address >>>>>>> space on s390x. All there is is memory. Therefore there is also not >>>>>>> really >>>>>>> an interface to communicate such information to the guest. All we can >>>>>>> do is >>>>>>> specify the maximum ram address and guests can probe in that range if >>>>>>> memory is available and usable (TPROT). >>>>>> >>>>>> In fact there is an interface in SCLP that describes the memory sizes >>>>>> (maximum in >>>>>> read scp info) and the details (read_storage_element0_info). I am >>>>>> asking myself >>>>>> if we should re-introduce read_storage_element_info and use that to >>>>>> avoid tprot >>>>> >>>>> Yes, we could do that (basically V1 of this patch) but have to glue it >>>>> to the a compatibility machine then. >>>> >>>> Actually, this makes quite a bit of sense (introduce the interface for >>>> everyone in 2.12 and turn it off in compat machines). >>> >>> Jup, either 2.12 or 2.13, no need to hurry. >>> >>>> >>>> Does real hardware have configurations where you can get the memory >>>> sizes, but not the attach/deattach support? (Hardware with the feature, >>>> but no standby memory defined?) > > We have different sclp facilities for attach/detach and information, so > we can implement that. > > >>> >>> I would guess that "0" for standby memory is valid but only people with >>> access to documentation can answer that :) >> >> So, should we go with this patch now and re-introduce the read >> functions if the above is indeed true? > > Yes, go with this patch. Right now Linux guests will not make use of that, so > we can re-add that if it turns out to be useful for future guests. > > > > Matt, last chance to complain with reasons why we want to keep the current > standby memory > solution in its current form. (Or please ack the patch if you agree)
Nope, this makes sense given its incompatibility w/ the common layer. I also agree with the prior comment that, should we revisit this feature in the future, it should probably be via an s390-specific interface. Acked-by: Matthew Rosato <mjros...@linux.vnet.ibm.com>
