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

[David Hildenbrand]

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.

> in the guests. Anyway that is future but maybe change your "TPROT" to sclp + 
> tprot.

Yes, makes sense.

> 
> 
>>
>> Also memory hotplug is strange. The guest can decide at some point in
>> time to add / remove memory in some range. And nobody can really hinder it
>> from doing so.
> 
> The host can reject to online an increment. For example on LPAR this is used 
> as
> a poor mans overcommitment. You can online prepared standy memory if there is
> enough memory left.

Interesting, didn't know about that. Will rephrase then to

"While the hypervisor can deny to online an increment, all increments
have to be predefined and there is no way of telling the guest about a
newly "hotplugged" increment."

> 
>  So if we specify right now e.g.
>>     -m 2G,slots=2,maxmem=20G
>> An ordinary fedora guest will happily online (hotplug) all memory,
>> resulting in a guest consuming 20G. So it really behaves rather like
>>     -m 22G
>> There is no way to hotplug memory from the outside like on other
>> architectures. This is of course bad for upper management layers.
> 
> This is the main issue with the current code.


-- 

Thanks,

David / dhildenb