From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47847) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UD0uP-0002wm-EH for qemu-devel@nongnu.org; Tue, 05 Mar 2013 18:04:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UD0uL-0004n7-JY for qemu-devel@nongnu.org; Tue, 05 Mar 2013 18:04:33 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41062) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UD0uL-0004mv-Bo for qemu-devel@nongnu.org; Tue, 05 Mar 2013 18:04:29 -0500 Message-ID: <51367A50.6040405@redhat.com> Date: Wed, 06 Mar 2013 00:05:52 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: <1362435597-20018-1-git-send-email-lersek@redhat.com> <1362435597-20018-2-git-send-email-lersek@redhat.com> <51365EC2.8050903@redhat.com> In-Reply-To: <51365EC2.8050903@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: Eric Blake Cc: Drew Jones , qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com, pbonzini@redhat.com, lcapitulino@redhat.com, Karen Noel On 03/05/13 22:08, Eric Blake wrote: > 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 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 -- 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 doesn't have "cpu_set". Thanks Laszlo