From: Cornelia Huck <cohuck@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
qemu-s390x@nongnu.org, qemu-devel@nongnu.org,
Richard Henderson <rth@twiddle.net>,
Alexander Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] [PATCH RFCv2] s390x/sclp: remove memory hotplug support
Date: Wed, 21 Feb 2018 18:39:18 +0100 [thread overview]
Message-ID: <20180221183918.7cc4fad1.cohuck@redhat.com> (raw)
In-Reply-To: <aeb36cb1-aadf-6146-9e59-549998538db1@redhat.com>
On Tue, 20 Feb 2018 16:05:54 +0100
David Hildenbrand <david@redhat.com> wrote:
> On 20.02.2018 15:57, Cornelia Huck wrote:
> > On Tue, 20 Feb 2018 13:16:37 +0100
> > David Hildenbrand <david@redhat.com> 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.
next prev parent reply other threads:[~2018-02-21 17:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-19 17:42 [Qemu-devel] [PATCH RFCv2] s390x/sclp: remove memory hotplug support David Hildenbrand
2018-02-20 11:18 ` Christian Borntraeger
2018-02-20 11:19 ` Christian Borntraeger
2018-02-20 11:46 ` David Hildenbrand
2018-02-20 12:05 ` Christian Borntraeger
2018-02-20 12:16 ` David Hildenbrand
2018-02-20 14:57 ` Cornelia Huck
2018-02-20 15:05 ` David Hildenbrand
2018-02-21 17:39 ` Cornelia Huck [this message]
2018-02-22 11:13 ` Christian Borntraeger
2018-02-22 19:29 ` Matthew Rosato
2018-02-23 9:34 ` Cornelia Huck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180221183918.7cc4fad1.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=agraf@suse.de \
--cc=borntraeger@de.ibm.com \
--cc=david@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).