qemu-devel
[Top][All Lists]
Advanced

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

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


From: Cornelia Huck
Subject: Re: [Qemu-devel] [PATCH RFCv2] s390x/sclp: remove memory hotplug support
Date: Wed, 21 Feb 2018 18:39:18 +0100

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

> 
> >> 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? :)  
> 
> "And nobody can really hinder it from doing so."

OK.



reply via email to

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