From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34926 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Phjuu-0002EM-18 for qemu-devel@nongnu.org; Tue, 25 Jan 2011 09:30:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Phjuk-00088o-Ad for qemu-devel@nongnu.org; Tue, 25 Jan 2011 09:30:35 -0500 Received: from mail-yw0-f45.google.com ([209.85.213.45]:56072) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Phjuk-00088i-83 for qemu-devel@nongnu.org; Tue, 25 Jan 2011 09:30:34 -0500 Received: by ywa8 with SMTP id 8so1548350ywa.4 for ; Tue, 25 Jan 2011 06:30:33 -0800 (PST) Message-ID: <4D3EDE87.1000005@codemonkey.ws> Date: Tue, 25 Jan 2011 08:30:31 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 28/35] kvm: x86: Introduce kvmclock device to save/restore its state References: <4D2B6CB5.9050602@codemonkey.ws> <4D2B74D8.4080309@web.de> <4D2B8662.9060909@web.de> <4D2C60FB.7030009@linux.vnet.ibm.com> <4D2D80ED.8030405@redhat.com> <4D2D82EE.20002@siemens.com> <4D35A39A.8000801@siemens.com> <4D35ABF8.9050700@linux.vnet.ibm.com> <4D35B521.3090601@siemens.com> <4D35B6DD.1020005@linux.vnet.ibm.com> <4D3717E7.3010105@linux.vnet.ibm.com> <4D3EAEB9.80803@redhat.com> In-Reply-To: <4D3EAEB9.80803@redhat.com> 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: Avi Kivity Cc: "kvm@vger.kernel.org" , Jan Kiszka , Glauber Costa , Marcelo Tosatti , Markus Armbruster , "qemu-devel@nongnu.org" On 01/25/2011 05:06 AM, Avi Kivity wrote: > On 01/19/2011 06:57 PM, Anthony Liguori wrote: >> On 01/19/2011 07:15 AM, Markus Armbruster wrote: >>> So they interact with KVM (need kvm_state), and they interact with the >>> emulated PCI bus. Could you elaborate on the fundamental difference >>> between the two interactions that makes you choose the (hypothetical) >>> KVM bus over the PCI bus as device parent? >> >> It's almost arbitrary, but I would say it's the direction that I/Os >> flow. >> > > In the case of kvm, things are somewhat misleading. I/O still flows > through the (virtual) PCI bus, it's just short-circuited to a real device. It doesn't. If we have a PCI bus that transforms I/O or remaps I/O via an IOMMU, that device doesn't participate in it. But this whole discussion is way off track. We don't have to solve any of these problems today. Just don't remove kvm_state and grab a global reference to it when we need to (which is *at best* one place in the code today) and let's move on with our lives. Regards, Anthony Liguori > Similarly when attaching an ioeventfd to a virtio kick register, > things still logically from the same way as without ioeventfd; we > simply add a fast path for the operation. But it doesn't change the > logical view of things. >