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

[Christian Borntraeger]

On 02/21/2018 06:39 PM, Cornelia Huck wrote:
> On Tue, 20 Feb 2018 16:05:54 +0100
> David Hildenbrand <address@hidden> wrote:
> 
>> On 20.02.2018 15:57, Cornelia Huck wrote:
>>> On Tue, 20 Feb 2018 13:16:37 +0100
>>> David Hildenbrand <address@hidden> 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)