qemu-devel
[Top][All Lists]
Advanced

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

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


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH 1/3] qga: introduce guest-get-vcpus / guest-set-vcpus with stubs
Date: Tue, 05 Mar 2013 14:08:18 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3

On 03/04/2013 03:19 PM, Laszlo Ersek wrote:
> Signed-off-by: Laszlo Ersek <address@hidden>
> ---

> +# @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: signature.asc
Description: OpenPGP digital signature


reply via email to

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