From: David Gibson <david@gibson.dropbear.id.au>
To: Andrea Bolognani <abologna@redhat.com>
Cc: groug@kaod.org, aik@ozlabs.ru, qemu-ppc@nongnu.org,
qemu-devel@nongnu.org, clg@kaod.org
Subject: Re: [Qemu-devel] [RFC for-2.13 0/7] spapr: Clean up pagesize handling
Date: Thu, 14 Jun 2018 11:52:39 +1000 [thread overview]
Message-ID: <20180614015239.GI3042@umbus.fritz.box> (raw)
In-Reply-To: <679d506dbec32c4978a03fe07f21de3e43fba2c0.camel@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2176 bytes --]
On Mon, May 07, 2018 at 03:48:54PM +0200, Andrea Bolognani wrote:
> On Fri, 2018-04-27 at 22:17 +1000, David Gibson wrote:
> > On Fri, Apr 27, 2018 at 10:31:10AM +0200, Andrea Bolognani wrote:
> > > On Fri, 2018-04-27 at 12:14 +1000, David Gibson wrote:
> > > > Right.. note that with the draft qemu patches a TCG guest will be
> > > > prevented from using hugepages *by default* (the default value of the
> > > > capability is 16). You have to explicitly change it to allow
> > > > hugepages to be used in a TCG guest (but you don't have to supply
> > > > hugepage backing).
> > >
> > > ... this will already happen. That's okay[1], we can't really
> > > avoid it if we want to ensure consistent behavior between KVM and
> > > TCG.
> >
> > So.. regarding [1]. The draft patches *do* change the behaviour on
> > older machine types. I'll consider revisiting that, but I'd need to
> > be convinced. Basically we have to choose between consistency between
> > accelerator and consistency between versions. I think the former is
> > the better choice; at least I think it is given that we *can* get both
> > for the overwhelmingly common case in production (KVM HV).
>
> Forgot to answer this point.
>
> I agree that consistency between accelerators is the sane option
> going forward, but changing the behavior for old machine types will
> cause existing guests which have been using hugepages to lose the
> ability to do so after being restarted on a newer QEMU.
>
> Isn't that exactly the kind of scenario versioned machine types are
> supposed to prevent?
Yeah, it is. What I was questioning was whether it was important
enough for the case of TCG and PR guests (which have never been as
well supported) to justify keeping the other inconsistency.
On reflection, I think it probably does.. and I also think I have a
way to preserve it without having to keep around masses of the old
code, so I'll adjust that for the next spin.
--
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 --]
prev parent reply other threads:[~2018-06-14 2:58 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
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 [this message]
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=20180614015239.GI3042@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=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 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).