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

[Eric Blake <eblake@redhat.com>]

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

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?  Or is it guaranteed that a subsequent
successful guest-get-vcpus will still be reliably to learn after the
fact what happened?  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 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).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


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