[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: |
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.
- [qemu-s390x] [PATCH RFCv2] s390x/sclp: remove memory hotplug support, David Hildenbrand, 2018/02/19
- Re: [qemu-s390x] [PATCH RFCv2] s390x/sclp: remove memory hotplug support, Christian Borntraeger, 2018/02/20
- Re: [qemu-s390x] [PATCH RFCv2] s390x/sclp: remove memory hotplug support, Christian Borntraeger, 2018/02/20
- Re: [qemu-s390x] [PATCH RFCv2] s390x/sclp: remove memory hotplug support, David Hildenbrand, 2018/02/20
- Re: [qemu-s390x] [PATCH RFCv2] s390x/sclp: remove memory hotplug support, Cornelia Huck, 2018/02/20
- Re: [qemu-s390x] [PATCH RFCv2] s390x/sclp: remove memory hotplug support, David Hildenbrand, 2018/02/20
- Re: [qemu-s390x] [PATCH RFCv2] s390x/sclp: remove memory hotplug support,
Cornelia Huck <=
- Re: [qemu-s390x] [PATCH RFCv2] s390x/sclp: remove memory hotplug support, Christian Borntraeger, 2018/02/22
- Re: [qemu-s390x] [Qemu-devel] [PATCH RFCv2] s390x/sclp: remove memory hotplug support, Matthew Rosato, 2018/02/22
- Re: [qemu-s390x] [Qemu-devel] [PATCH RFCv2] s390x/sclp: remove memory hotplug support, Cornelia Huck, 2018/02/23