Re: [Qemu-devel] [PATCH 1/3] qga: introduce guest-get-vcpus / guest-set-vcpus with stubs

[Laszlo Ersek <lersek@redhat.com>]

On 03/05/13 22:08, Eric Blake wrote:
> On 03/04/2013 03:19 PM, Laszlo Ersek wrote:
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
> 
>> +# @guest-set-vcpus:
>> +#
>> +# Attempt to reconfigure (currently: enable/disable) logical processors inside
>> +# the guest.
>> +#
>> +# The input list is processed node by node in order. In each node @logical-id
>> +# is used to look up the guest VCPU, for which @online specifies the requested
>> +# state. The set of distinct @logical-id's is only required to be a subset of
>> +# guest-supported identifiers. There's no restriction on list length or on
>> +# repeating the same @logical-id (with possibly different @online field).
>> +# Preferably the input list should describe a modified subset of
>> +# @guest-get-vcpus' return value.
>> +#
>> +# If part or whole of the requested operation can't be carried out, the guest
>> +# VCPU state will be unspecified.
> 
> Completely unspecified?

Yes. "Unspecified" means "valid" (ie. at least one VCPU will be online,
the guest won't be "dead"), but no further info will be returned at once.

> Or is it guaranteed that a subsequent
> successful guest-get-vcpus will still be reliably to learn after the
> fact what happened?

Yes, that is both the intent and implied by "unspecified" (as opposed to
"undefined").

> Would it make any more sense to have only a
> guest-set-vcpu, which attempts to set the state of a single vcpu,
> instead of an open-ended array of successive vcpu modifications in
> guest-set-vcpus?

The current interface can be special-cased into that type of call,
however I wanted to provide a batch interface (flipping 100 VCPUs
shouldn't take 100 round trips).

> The interface seems relatively sane, though, and it looks like something
> that libvirt would be able to use without having to add any new APIs
> (just a new flag value to the existing virDomainSetVcpusFlags() function).

Oh.

virDomainSetVcpusFlags() [src/libvirt.c]
  qemuDomainSetVcpusFlags() [src/qemu/qemu_driver.c]
    qemuDomainHotplugVcpus()
      qemuMonitorSetCPU() [src/qemu/qemu_monitor.c]
        qemuMonitorTextSetCPU()
          "cpu_set %d %s"

Does this work? I can't find any trace of the "cpu_set" (or the
"set_cpu") monitor command in upstream qemu.

The relevant libvirt commits are:
- e8d6c289 Support VCPU hotplug in QEMU guests
  ("NB, currently untested since QEMU segvs when running this!")
- a980d123 Fix CPU hotplug command names

If this works and I'm just not seeing something then I have no reason to
pursue this series.

... Ah I understand now. "cpu_set" *is* supported by the qemu-kvm
project at <git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git> -- and
by RHEL-6 qemu-kvm --, via ACPI.

I'll have to test this in RHEL-6. If it doesn't work, I should check
why. If it does, I'll have to figure out if I should continue to work on
this.

I wonder why <git://git.qemu.org/qemu.git> doesn't have "cpu_set".

Thanks
Laszlo