From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments Date: Tue, 11 Jan 2011 08:09:35 -0600 Message-ID: <4D2C649F.6080508@linux.vnet.ibm.com> References: <4D2616D6.4080309@linux.vnet.ibm.com> <4D26D6CF.5070405@web.de> <4D27A16F.9030809@linux.vnet.ibm.com> <4D282489.90506@web.de> <4D2B6506.6070907@linux.vnet.ibm.com> <4D2B6845.7050809@web.de> <4D2B6ADD.4090505@codemonkey.ws> <4D2C1C5D.2050504@redhat.com> <4D2C6290.1060607@linux.vnet.ibm.com> <1EA102F5-B6C2-43BC-9493-0271B287FC18@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Jan Kiszka , Marcelo Tosatti , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Alexander Graf Return-path: Received: from e2.ny.us.ibm.com ([32.97.182.142]:52820 "EHLO e2.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932075Ab1AKOKb (ORCPT ); Tue, 11 Jan 2011 09:10:31 -0500 Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e2.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0BDr3R9008808 for ; Tue, 11 Jan 2011 08:53:09 -0500 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id F3380728065 for ; Tue, 11 Jan 2011 09:10:25 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0BEAPrg123162 for ; Tue, 11 Jan 2011 09:10:25 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0BEAPPM006129 for ; Tue, 11 Jan 2011 09:10:25 -0500 In-Reply-To: <1EA102F5-B6C2-43BC-9493-0271B287FC18@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: On 01/11/2011 08:06 AM, Alexander Graf wrote: > On 11.01.2011, at 15:00, Anthony Liguori wrote: > > >> On 01/11/2011 03:01 AM, Avi Kivity wrote: >> >>> On 01/10/2011 10:23 PM, Anthony Liguori wrote: >>> >>>>>> I don't see how ioapic, pit, or pic have a system scope. >>>>>> >>>>> They are not bound to any CPU like the APIC which you may have in mind. >>>>> >>>> And none of the above interact with KVM. >>>> >>> They're implemented by kvm. What deeper interaction do you have in mind? >>> >> The emulated ioapic/pit/pic do not interact with KVM at all. >> >> The KVM versions should be completely separate devices. >> >> >>> >>>> They may be replaced by KVM but if you look at the PIT, this is done by having two distinct devices. The KVM specific device can (and should) be instantiated with kvm_state. >>>> >>>> The way the IOAPIC/APIC/PIC is handled in qemu-kvm is nasty. The kernel devices are separate devices and that should be reflected in the device tree. >>>> >>> I don't see why. Those are just two different implementations for the same guest visible device. >>> >> Right, they should appear the same to the guest but the fact that they're two different implementations should be reflected in the device tree. >> >> >>> It's like saying IDE should be seen differently if it's backed by qcow2 or qed. >>> >> No, it's not at all. >> >> Advantages of separating KVM devices: >> >> 1) it becomes very clear what functionality is handled in the kernel verses in userspace (you can actually look at the code and tell) >> >> 2) a user can explicitly create either the emulated version of the device or the in-kernel version of the device (no need for -no-kvm-irqchip) >> >> 3) a user can pass parameters directly to the in-kernel version of the device that are different from the userspace version (like selecting different interrupt catch-up methods) >> > Disadvantages: > > 1) you lose migration / savevm between KVM and non-KVM VMs > This doesn't work today and it's never worked. KVM exposes things that TCG cannot emulate (like pvclock). Even as two devices, nothing prevents it from working. Both devices just have to support each other's savevm format. If they use the same code, it makes it very easy. Take a look at how the KVM PIT is implemented for an example of this. Regards, Anthony Liguori > I'm not saying this is unsolvable, but it's certainly something that bothers me :). Some sort of meta-device for KVM implemented devices and emulated devices would be nice. That device would then be the one state gets saved/restored from. > > > Alex > > From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50933 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pcevg-0006Pc-BS for qemu-devel@nongnu.org; Tue, 11 Jan 2011 09:10:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pcevd-0001gF-O6 for qemu-devel@nongnu.org; Tue, 11 Jan 2011 09:10:32 -0500 Received: from e3.ny.us.ibm.com ([32.97.182.143]:43564) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pcevd-0001g7-IT for qemu-devel@nongnu.org; Tue, 11 Jan 2011 09:10:29 -0500 Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e3.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0BDpa3x031812 for ; Tue, 11 Jan 2011 08:51:38 -0500 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id A91944DE8041 for ; Tue, 11 Jan 2011 09:07:25 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0BEAPRf1941524 for ; Tue, 11 Jan 2011 09:10:25 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0BEAPPG006129 for ; Tue, 11 Jan 2011 09:10:25 -0500 Message-ID: <4D2C649F.6080508@linux.vnet.ibm.com> Date: Tue, 11 Jan 2011 08:09:35 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments References: <4D2616D6.4080309@linux.vnet.ibm.com> <4D26D6CF.5070405@web.de> <4D27A16F.9030809@linux.vnet.ibm.com> <4D282489.90506@web.de> <4D2B6506.6070907@linux.vnet.ibm.com> <4D2B6845.7050809@web.de> <4D2B6ADD.4090505@codemonkey.ws> <4D2C1C5D.2050504@redhat.com> <4D2C6290.1060607@linux.vnet.ibm.com> <1EA102F5-B6C2-43BC-9493-0271B287FC18@suse.de> In-Reply-To: <1EA102F5-B6C2-43BC-9493-0271B287FC18@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Marcelo Tosatti , Jan Kiszka , Avi Kivity , kvm@vger.kernel.org, qemu-devel@nongnu.org On 01/11/2011 08:06 AM, Alexander Graf wrote: > On 11.01.2011, at 15:00, Anthony Liguori wrote: > > >> On 01/11/2011 03:01 AM, Avi Kivity wrote: >> >>> On 01/10/2011 10:23 PM, Anthony Liguori wrote: >>> >>>>>> I don't see how ioapic, pit, or pic have a system scope. >>>>>> >>>>> They are not bound to any CPU like the APIC which you may have in mind. >>>>> >>>> And none of the above interact with KVM. >>>> >>> They're implemented by kvm. What deeper interaction do you have in mind? >>> >> The emulated ioapic/pit/pic do not interact with KVM at all. >> >> The KVM versions should be completely separate devices. >> >> >>> >>>> They may be replaced by KVM but if you look at the PIT, this is done by having two distinct devices. The KVM specific device can (and should) be instantiated with kvm_state. >>>> >>>> The way the IOAPIC/APIC/PIC is handled in qemu-kvm is nasty. The kernel devices are separate devices and that should be reflected in the device tree. >>>> >>> I don't see why. Those are just two different implementations for the same guest visible device. >>> >> Right, they should appear the same to the guest but the fact that they're two different implementations should be reflected in the device tree. >> >> >>> It's like saying IDE should be seen differently if it's backed by qcow2 or qed. >>> >> No, it's not at all. >> >> Advantages of separating KVM devices: >> >> 1) it becomes very clear what functionality is handled in the kernel verses in userspace (you can actually look at the code and tell) >> >> 2) a user can explicitly create either the emulated version of the device or the in-kernel version of the device (no need for -no-kvm-irqchip) >> >> 3) a user can pass parameters directly to the in-kernel version of the device that are different from the userspace version (like selecting different interrupt catch-up methods) >> > Disadvantages: > > 1) you lose migration / savevm between KVM and non-KVM VMs > This doesn't work today and it's never worked. KVM exposes things that TCG cannot emulate (like pvclock). Even as two devices, nothing prevents it from working. Both devices just have to support each other's savevm format. If they use the same code, it makes it very easy. Take a look at how the KVM PIT is implemented for an example of this. Regards, Anthony Liguori > I'm not saying this is unsolvable, but it's certainly something that bothers me :). Some sort of meta-device for KVM implemented devices and emulated devices would be nice. That device would then be the one state gets saved/restored from. > > > Alex > >