From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38904) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCz6Y-0005vD-5I for qemu-devel@nongnu.org; Tue, 05 Mar 2013 16:09:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UCz6A-0003YV-Qy for qemu-devel@nongnu.org; Tue, 05 Mar 2013 16:08:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57014) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCz6A-0003UJ-Bv for qemu-devel@nongnu.org; Tue, 05 Mar 2013 16:08:34 -0500 Message-ID: <51365EC2.8050903@redhat.com> Date: Tue, 05 Mar 2013 14:08:18 -0700 From: Eric Blake MIME-Version: 1.0 References: <1362435597-20018-1-git-send-email-lersek@redhat.com> <1362435597-20018-2-git-send-email-lersek@redhat.com> In-Reply-To: <1362435597-20018-2-git-send-email-lersek@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2HCDSLTIUXEBAQQRCUQCK" Subject: Re: [Qemu-devel] [PATCH 1/3] qga: introduce guest-get-vcpus / guest-set-vcpus with stubs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: qemu-devel@nongnu.org, pbonzini@redhat.com, mdroth@linux.vnet.ibm.com, lcapitulino@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2HCDSLTIUXEBAQQRCUQCK Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/04/2013 03:19 PM, Laszlo Ersek wrote: > Signed-off-by: Laszlo Ersek > --- > +# @guest-set-vcpus: > +# > +# Attempt to reconfigure (currently: enable/disable) logical processor= s inside > +# the guest. > +# > +# The input list is processed node by node in order. In each node @log= ical-id > +# is used to look up the guest VCPU, for which @online specifies the r= equested > +# state. The set of distinct @logical-id's is only required to be a su= bset of > +# guest-supported identifiers. There's no restriction on list length o= r on > +# repeating the same @logical-id (with possibly different @online fiel= d). > +# 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, th= e 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)= =2E --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2HCDSLTIUXEBAQQRCUQCK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJRNl7CAAoJEKeha0olJ0Nq1dQH/iCuTAD/K9UyMiyh0ABTqmeG G41HRwkfNdt0D1gpwIcii063PkySdz7Va8sISWp0jgnFSKZbItMeiG+VYz/5hd4e jQpLMezDWaPyobOvJ0yOp0W4rfUhiKWMiICccG2FMCdtHD2sTCyGROOSkv8kksUX hnNKhWEtzr3nJUV4A/Q79lqSeszdaQtCSpHVdXKHUJDlXt8yOqUsExLOQGOB9Pen hXRG6TTWSseYdv9gdWcW1Hb7WwvgwkV9uRoT1o0xVTaCjQ8rBX3xTbypkml5pvFv XEPBkcMECN0YawPYH7x4kjJWDDRbvfC8Uxk4+OtQ6eEZo89ekSfy8s0Os/DBQoc= =lU/W -----END PGP SIGNATURE----- ------enig2HCDSLTIUXEBAQQRCUQCK--