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

[Matthew Rosato <mjrosato@linux.vnet.ibm.com>]

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>