From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35940) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RqMqb-00041e-Vf for qemu-devel@nongnu.org; Thu, 26 Jan 2012 05:46:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RqMqX-000208-Nn for qemu-devel@nongnu.org; Thu, 26 Jan 2012 05:46:29 -0500 Received: from mx1.redhat.com ([209.132.183.28]:29512) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RqMqX-000201-E9 for qemu-devel@nongnu.org; Thu, 26 Jan 2012 05:46:25 -0500 Message-ID: <4F212EFA.1020204@redhat.com> Date: Thu, 26 Jan 2012 12:46:18 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1327399808-31081-1-git-send-email-vasilis.liaskovitis@profitbricks.com> <1327399808-31081-4-git-send-email-vasilis.liaskovitis@profitbricks.com> <4F1E87D9.6000008@siemens.com> <20120124145600.GA6555@dhcp-192-168-178-175.profitbricks.localdomain> In-Reply-To: <20120124145600.GA6555@dhcp-192-168-178-175.profitbricks.localdomain> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 3/4] uq/master: Add CPU eject handling for acpi_piix4 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vasilis Liaskovitis Cc: "mtosatti@redhat.com" , "kvm@vger.kernel.org" , "gleb@redhat.com" , Jan Kiszka , "seabios@seabios.org" , "qemu-devel@nongnu.org" , kernelfans@gmail.com, "kevin@koconnor.net" On 01/24/2012 04:56 PM, Vasilis Liaskovitis wrote: > On Tue, Jan 24, 2012 at 11:28:41AM +0100, Jan Kiszka wrote: > > On 2012-01-24 11:10, Vasilis Liaskovitis wrote: > > > Add stub functions for CPU eject callback. Define cpu_acpi_eject property and > > > enable eject callback only for pc-1.1 machine model. > > > > Just to get the idea: What is the plan and advantage of introducing a > > stub first? How much more is required to have some usable feature, even > > if its just a friction of the full support? > > > There's not really an advantage to adding stubs first. The plan depends on the > lifecycle patches getting accepted in some form at some point. The code is all > out there, and some of it has been reviewed/commented on, but not accepted. > > kvm needs the following patches: > https://lkml.org/lkml/2012/1/6/355 (v7, still in work) > http://patchwork.ozlabs.org/patch/127828/ > This second patch introduces ioctl KVM_SETSTATE_VCPU, (qemu uses it to signal > vcpu destruction to the host) but the review mentions there should be a > simpler way. It's unclear to me whether this ioctl is desired or not. Those patches are not strictly needed. On a kernel that doesn't have them, you can simply park the vcpu thread in userspace until it is re-added. I suggest writing the qemu patches without the assumption that you're running on a 3.4+ kernel. -- error compiling committee.c: too many arguments to function