From mboxrd@z Thu Jan 1 00:00:00 1970 From: Blue Swirl Subject: Re: [Qemu-devel] [PATCH 28/35] kvm: x86: Introduce kvmclock device to save/restore its state Date: Wed, 19 Jan 2011 19:32:13 +0000 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Markus Armbruster , "kvm@vger.kernel.org" , Jan Kiszka , Glauber Costa , Marcelo Tosatti , "qemu-devel@nongnu.org" , Avi Kivity To: Anthony Liguori Return-path: Received: from mail-px0-f174.google.com ([209.85.212.174]:44866 "EHLO mail-px0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753014Ab1ASTcd convert rfc822-to-8bit (ORCPT ); Wed, 19 Jan 2011 14:32:33 -0500 Received: by pxi15 with SMTP id 15so219737pxi.19 for ; Wed, 19 Jan 2011 11:32:33 -0800 (PST) In-Reply-To: <4D3717E7.3010105@linux.vnet.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Jan 19, 2011 at 4: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 t= he >> emulated PCI bus. =C2=A0Could you elaborate on the fundamental diffe= rence >> 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 f= low. > > But if the underlying observation is that the device tree is not real= ly a > tree, you're 100% correct. =C2=A0This is part of why a factory interf= ace that > just takes a parent bus is too simplistic. > > I think we ought to introduce a -pci-device option that is specifical= ly for > creating PCI devices that doesn't require a parent bus argument but p= rovides > a way to specify stable addressing (for instancing, using a linear in= dex). I think kvm_state should not be a property of any device or bus. It should be split to more logical pieces. Some parts of it could remain in CPUState, because they are associated with a VCPU. Also, for example irqfd could be considered to be similar object to char or block devices provided by QEMU to devices. Would it make sense to introduce new host types for passing parts of kvm_state to devices? I'd also make coalesced MMIO stuff part of memory object. We are not passing any state references when using cpu_physical_memory_rw(), but that could be changed. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53806 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pfdlp-0007c2-HN for qemu-devel@nongnu.org; Wed, 19 Jan 2011 14:32:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pfdli-0002E9-N3 for qemu-devel@nongnu.org; Wed, 19 Jan 2011 14:32:41 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:47904) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pfdli-0002Dt-El for qemu-devel@nongnu.org; Wed, 19 Jan 2011 14:32:34 -0500 Received: by pwj6 with SMTP id 6so248823pwj.4 for ; Wed, 19 Jan 2011 11:32:33 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4D3717E7.3010105@linux.vnet.ibm.com> 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> From: Blue Swirl Date: Wed, 19 Jan 2011 19:32:13 +0000 Message-ID: Subject: Re: [Qemu-devel] [PATCH 28/35] kvm: x86: Introduce kvmclock device to save/restore its state Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "kvm@vger.kernel.org" , Jan Kiszka , Glauber Costa , Marcelo Tosatti , Markus Armbruster , "qemu-devel@nongnu.org" , Avi Kivity On Wed, Jan 19, 2011 at 4: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. =C2=A0Could you elaborate on the fundamental differenc= e >> 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. > > But if the underlying observation is that the device tree is not really a > tree, you're 100% correct. =C2=A0This is part of why a factory interface = that > just takes a parent bus is too simplistic. > > I think we ought to introduce a -pci-device option that is specifically f= or > creating PCI devices that doesn't require a parent bus argument but provi= des > a way to specify stable addressing (for instancing, using a linear index)= . I think kvm_state should not be a property of any device or bus. It should be split to more logical pieces. Some parts of it could remain in CPUState, because they are associated with a VCPU. Also, for example irqfd could be considered to be similar object to char or block devices provided by QEMU to devices. Would it make sense to introduce new host types for passing parts of kvm_state to devices? I'd also make coalesced MMIO stuff part of memory object. We are not passing any state references when using cpu_physical_memory_rw(), but that could be changed.