qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [PATCHv3 for-2.9 0/6] HPT resizing for pseries guests (qe


From: David Gibson
Subject: Re: [Qemu-ppc] [PATCHv3 for-2.9 0/6] HPT resizing for pseries guests (qemu part)
Date: Tue, 20 Dec 2016 10:47:17 +1100
User-agent: Mutt/1.7.1 (2016-10-04)

On Mon, Dec 19, 2016 at 04:15:29PM +0100, Andrea Bolognani wrote:
> On Thu, 2016-12-15 at 17:11 +1100, David Gibson wrote:
> > This series implements the host side of the PAPR ACR to allow runtime
> > resizing of the Hashed Page Table (HPT) for pseries guests.
> [...]
> > Availability of the feature is controlled by a new 'resize-hpt'
> > machine option: it can be set to "disabled", "enabled" or "required".
> 
> IIUC resize-hpt will be enabled by default for pseries-2.9
> and newer.

That's the plan.

> Do we want to expose a knob for controlling this
> to the user at the libvirt level, or should we just enable
> resize-hpt unconditionally whenever we detect that the QEMU
> binary supports it?

I'm not sure if we need a knob.  I think in general enabling for
pseries-2.9 and later machine types is correct.  The difficulty is
that for HV guests, we can only enable it if the host kernel also has
support.  Explicitly setting "resize-hpt=enable" means qemu will not
start if the kernel doesn't support it.

My inclination would be to enable unconditionally for pseries-2.9 and
later machine types.

> Does enabling this change the guest ABI at all?

It extends the guest ABI, but in a backwards compatible way.

> If so, we
> can't do the latter because it would cause existing guests
> to undergo an ABI change when QEMU is upgraded.

Well, I wouldn't recommend turning it on for the existing machine
types.  That said, you should get away with it anyway: if the guest
boots anew, the resizing should get disabled again by the feature
negotiation (unless the guest understands it, in which case no
problem).  If the guest is migrated in already booted the resizing
feature will be technically present, but since the guest won't attempt
to use it, it won't matter.  The current HPT size is already
transferred as part of the migration stream, so the altered logic
about allocating it won't affect migrated guests.

-- 
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: signature.asc
Description: PGP signature


reply via email to

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