qemu-s390x
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Cornelia Huck
Subject: Re: [qemu-s390x] [PATCH RFCv2] s390x/sclp: remove memory hotplug support
Date: Tue, 20 Feb 2018 15:57:59 +0100

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).

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?)

> 
> > 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."

Rephrase which part? :)

> 
> > 
> >  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.  
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]