Re: [Qemu-devel] [PATCH RFCv2] s390x/sclp: remove memory hotplug support

[Cornelia Huck <cohuck@redhat.com>]

On Thu, 22 Feb 2018 14:29:09 -0500
Matthew Rosato <mjrosato@linux.vnet.ibm.com> wrote:

> 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 <david@redhat.com> wrote:
> >>  
> >>> On 20.02.2018 15:57, Cornelia Huck wrote:  
> >>>> On Tue, 20 Feb 2018 13:16:37 +0100
> >>>> David Hildenbrand <david@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 <mjrosato@linux.vnet.ibm.com>

Thanks, applied (with the discussed description tweak) to s390-next.

We should also mention this in the changelog once this hits master.
I'll try to remember to do that.