qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-ppc] [PATCHv3 for-2.9 0/6] HPT resizing for pseri


From: David Gibson
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCHv3 for-2.9 0/6] HPT resizing for pseries guests (qemu part)
Date: Thu, 22 Dec 2016 09:43:26 +1100
User-agent: Mutt/1.7.1 (2016-10-04)

On Wed, Dec 21, 2016 at 09:38:17AM +0100, Andrea Bolognani wrote:
> On Wed, 2016-12-21 at 15:52 +1100, David Gibson wrote:
> > > > 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.
> > > 
> > > I thought that would be the case for resize-hpt=required,
> > > not resized-hpt=enabled.
>
> > resize-hpt=enabled requires the host to support resizing, but not the
> > guest.  resize-hpt=required requires both the host and the guest to
> > support resizing.
>
> > If you can think of a less ambiguous word for it, let me know.
> 
> The name makes sense, we just need to document the host
> kernel requirement properly. The error message should of
> course mention it as well.

The error message is currently

"Hash page table resizing not available with this KVM version"

Does that cover it?

> > > Moreover, do you foresee any situation in which users
> > > might reasonably want to turn the feature off even though
> > > the entire stack (host kernel, QEMU, guest kernel)
> > > understands it?
>
> > Nothing clearly compelling.  In the nearish term, being able to turn
> > it off to isolate possible bugs could be useful of course.  It's also
> > possible that you could have a VM where the latency of each resize
> > could be too much downtime - although in that case I doubt you'd want
> > to hotplug memory anyway.
> 
> It seems like the use case would be fairly narrow, if it
> existed at all. Given that, I think we should avoid adding
> yet another knob to libvirt until its value can be
> unquestionably proven.

I tend to agree.

-- 
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]