From: David Gibson <david@gibson.dropbear.id.au>
To: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
Cc: groug@kaod.org, abologna@redhat.com, aik@ozlabs.ru,
qemu-ppc@nongnu.org, qemu-devel@nongnu.org, clg@kaod.org
Subject: Re: [Qemu-devel] [RFC for-2.13 1/7] spapr: Maximum (HPT) pagesize property
Date: Thu, 3 May 2018 11:34:32 +1000 [thread overview]
Message-ID: <20180503013432.GA3267@umbus.fritz.box> (raw)
In-Reply-To: <20180502210637.GA27693@kermit-br-ibm-com>
[-- Attachment #1: Type: text/plain, Size: 4007 bytes --]
On Wed, May 02, 2018 at 06:06:38PM -0300, Murilo Opsfelder Araujo wrote:
> On Thu, Apr 19, 2018 at 04:29:11PM +1000, David Gibson wrote:
> > The way the POWER Hash Page Table (HPT) MMU is virtualized by KVM HV means
> > that every page that the guest puts in the pagetables must be truly
> > physically contiguous, not just GPA-contiguous. In effect this means that
> > an HPT guest can't use any pagesizes greater than the host page size used
> > to back its memory.
> >
> > At present we handle this by changing what we advertise to the guest based
> > on the backing pagesizes. This is pretty bad, because it means the guest
> > sees a different environment depending on what should be host configuration
> > details.
> >
> > As a start on fixing this, we add a new capability parameter to the pseries
> > machine type which gives the maximum allowed pagesizes for an HPT guest (as
> > a shift). For now we just create and validate the parameter without making
> > it do anything.
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > ---
> > hw/ppc/spapr.c | 1 +
> > hw/ppc/spapr_caps.c | 53 ++++++++++++++++++++++++++++++++++++++++++++++++++
> > include/hw/ppc/spapr.h | 4 +++-
> > 3 files changed, 57 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > index bdf72e1e89..36e41aff71 100644
> > --- a/hw/ppc/spapr.c
> > +++ b/hw/ppc/spapr.c
> > @@ -3876,6 +3876,7 @@ static void spapr_machine_class_init(ObjectClass *oc, void *data)
> > smc->default_caps.caps[SPAPR_CAP_CFPC] = SPAPR_CAP_BROKEN;
> > smc->default_caps.caps[SPAPR_CAP_SBBC] = SPAPR_CAP_BROKEN;
> > smc->default_caps.caps[SPAPR_CAP_IBS] = SPAPR_CAP_BROKEN;
> > + smc->default_caps.caps[SPAPR_CAP_HPT_MPS] = 16; /* Allow 64kiB pages */
> > spapr_caps_add_properties(smc, &error_abort);
> > }
> >
> > diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
> > index 531e145114..cbc41f5b20 100644
> > --- a/hw/ppc/spapr_caps.c
> > +++ b/hw/ppc/spapr_caps.c
> > @@ -27,6 +27,7 @@
> > #include "qapi/visitor.h"
> > #include "sysemu/hw_accel.h"
> > #include "target/ppc/cpu.h"
> > +#include "target/ppc/mmu-hash64.h"
> > #include "cpu-models.h"
> > #include "kvm_ppc.h"
> >
> > @@ -142,6 +143,39 @@ out:
> > g_free(val);
> > }
> >
> > +static void spapr_cap_get_int(Object *obj, Visitor *v, const char *name,
> > + void *opaque, Error **errp)
> > +{
> > + sPAPRCapabilityInfo *cap = opaque;
> > + sPAPRMachineState *spapr = SPAPR_MACHINE(obj);
> > + int64_t value = spapr_get_cap(spapr, cap->index);
> > +
> > + visit_type_int(v, name, &value, errp);
> > +}
> > +
> > +static void spapr_cap_set_int(Object *obj, Visitor *v, const char *name,
> > + void *opaque, Error **errp)
> > +{
> > + sPAPRCapabilityInfo *cap = opaque;
> > + sPAPRMachineState *spapr = SPAPR_MACHINE(obj);
> > + int64_t value;
> > + Error *local_err = NULL;
> > +
> > + visit_type_int(v, name, &value, &local_err);
> > + if (local_err) {
> > + error_propagate(errp, local_err);
> > + return;
> > + }
> > +
> > + if ((value < 0) || (value > 255)) {
> > + error_setg(errp, "Value for %s out of range (0..255)", name);
> > + return;
> > + }
> > +
> > + spapr->cmd_line_caps[cap->index] = true;
> > + spapr->eff.caps[cap->index] = value;
> > +}
> > +
>
> Hi, David.
>
> Do you think uint8_t would fit better for spapr_[gs]et_int() functions?
>
> Perhaps renaming them to spapr_[gs]set_int8() and calling
> visit_type_int8() instead.
Yeah, that's a good idea. Using visit_type_uint8 means we don't need
to implement our own clamping.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-05-03 2:15 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-19 6:29 [Qemu-devel] [RFC for-2.13 0/7] spapr: Clean up pagesize handling David Gibson
2018-04-19 6:29 ` [Qemu-devel] [RFC for-2.13 1/7] spapr: Maximum (HPT) pagesize property David Gibson
2018-05-02 21:06 ` Murilo Opsfelder Araujo
2018-05-03 1:34 ` David Gibson [this message]
2018-04-19 6:29 ` [Qemu-devel] [RFC for-2.13 2/7] spapr: Use maximum page size capability to simplify memory backend checking David Gibson
2018-04-19 6:29 ` [Qemu-devel] [RFC for-2.13 3/7] target/ppc: Add ppc_hash64_filter_pagesizes() David Gibson
2018-05-03 15:57 ` Murilo Opsfelder Araujo
2018-05-04 6:30 ` David Gibson
2018-04-19 6:29 ` [Qemu-devel] [RFC for-2.13 4/7] spapr: Add cpu_apply hook to capabilities David Gibson
2018-04-19 6:29 ` [Qemu-devel] [RFC for-2.13 5/7] spapr: Limit available pagesizes to provide a consistent guest environment David Gibson
2018-04-19 6:29 ` [Qemu-devel] [RFC for-2.13 6/7] spapr: Don't rewrite mmu capabilities in KVM mode David Gibson
2018-04-19 6:29 ` [Qemu-devel] [RFC for-2.13 7/7] spapr_pci: Remove unhelpful pagesize warning David Gibson
2018-04-19 15:30 ` [Qemu-devel] [RFC for-2.13 0/7] spapr: Clean up pagesize handling Andrea Bolognani
2018-04-20 2:35 ` David Gibson
2018-04-20 9:31 ` Andrea Bolognani
2018-04-20 10:21 ` David Gibson
2018-04-23 8:31 ` Andrea Bolognani
2018-04-24 1:26 ` David Gibson
2018-04-24 15:35 ` Andrea Bolognani
2018-04-25 6:32 ` David Gibson
2018-04-25 16:09 ` Andrea Bolognani
2018-04-26 0:55 ` David Gibson
2018-04-26 8:45 ` Andrea Bolognani
2018-04-27 2:14 ` David Gibson
2018-04-27 8:31 ` Andrea Bolognani
2018-04-27 12:17 ` David Gibson
2018-05-07 13:48 ` Andrea Bolognani
2018-06-14 1:52 ` David Gibson
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=20180503013432.GA3267@umbus.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=abologna@redhat.com \
--cc=aik@ozlabs.ru \
--cc=clg@kaod.org \
--cc=groug@kaod.org \
--cc=muriloo@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.