Re: [Qemu-devel] [PATCH 1/3] qapi: Report support for -device cpu hotplug in query-machines

[David Gibson <dgibson@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2989 bytes --]

On Fri, 24 Jun 2016 07:41:11 +0200
Peter Krempa <pkrempa@redhat.com> wrote:

> On Fri, Jun 24, 2016 at 14:56:51 +1000, David Gibson wrote:
> 
> [...]
> 
> > > You are correct - query-commands says whether 'query-hotpluggable-cpus'
> > > exists as a command.  But that is insufficient.  See my review, or the
> > > v2 patch, where the above poor wording was corrected to say what was
> > > really meant: knowing whether query-hotpluggable-cpus exists is
> > > insufficient to tell you whether a given cpu type can be hotplugged.  So
> > > adding one more piece of witness (for every type of cpu supported, we
> > > also advertise if it is hotpluggable) is enough for libvirt to
> > > efficiently take advantage of the new query-hotpluggable-cpus command.  
> > 
> > Ah, right.  Or to put it another way, the availability of
> > query-hotpluggable-cpus is global across qemu, whereas actually being
> > able to use it for hotplug is per machine type.
> > 
> > Would it be possible to do this instead by attempting to invoke
> > query-hopluggable-cpus and seeing if it returns any information?  
> 
> It is not strictly necessary for us to have this in the context of
> usability. If the user requests using the new hotplug feature we will
> try it unconditionally and call query-hotpluggable-cpus before even
> starting guest execution. A failure to query the state will then result
> in termination of the VM.

Oh.. I wasn't expecting the feature would be enabled at user request -
I thought libvirt would just use it if available.

> It is necessary though to report the availability of the feature to the
> user via our domain capabilities API which some higher layer management
> apps use to make decisions.

Right... what advantage does adding the machine flag have over
attempting the query-hotpluggable-cpus?

> This would also be necessary if we wanted to switch by default to the
> new approach, but that's not really possible as libvirt tries to
> guarantee that a config valid on certain version will be still valid
> even when it was migrated to a newer version and then back.

Sorry, I've lost track of what the "This" is that would be necessary.

> My current plan is to start qemu with -smp cpus=1,... and then call
> query-hotpluggable-cpus and then hotplug all of them until the requested
> configuration is satisfied. This approach is necessary so that we can
> query for the model and topology info so that we don't need to
> re-implement all the numbering and naming logic from qemu.

Um.. why?  What's the problem with just staring with -smp cpus=whatever
and then using query-hotpluggable-cpus?

> Additionally this will require us to mark one CPU as non-hotpluggable as
> -smp cpus=0,maxcpus=10 is basically translated to -smp
> cpus=10,maxcpus=10.

The latter is true, but I'm not clear why it implies the former.

-- 
David Gibson <dgibson@redhat.com>
Senior Software Engineer, Virtualization, Red Hat

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]