From mboxrd@z Thu Jan  1 00:00:00 1970
From: Anthony Liguori <aliguori@linux.vnet.ibm.com>
Subject: Re: [PATCH 28/35] kvm: x86: Introduce kvmclock device
	to save/restore its state
Date: Wed, 19 Jan 2011 10:57:11 -0600
Message-ID: <4D3717E7.3010105@linux.vnet.ibm.com>
References: <cover.1294336601.git.mtosatti@redhat.com>
	<db8685e3925e7a5593e3f96ae703e1d19ef2fb0b.1294336601.git.mtosatti@redhat.com>
	<4D2B6CB5.9050602@codemonkey.ws> <4D2B74D8.4080309@web.de>
	<4D2B8662.9060909@web.de> <m339ozwzvj.fsf@blackfin.pond.sub.org>
	<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>
	<m339opnifa.fsf@blackfin.pond.sub.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Jan Kiszka <jan.kiszka@siemens.com>, Glauber Costa <glommer@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Avi Kivity <avi@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Return-path: <qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org>
In-Reply-To: <m339opnifa.fsf@blackfin.pond.sub.org>
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
List-Id: kvm.vger.kernel.org

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.

But if the underlying observation is that the device tree is not really 
a tree, you're 100% correct.  This 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 
for creating PCI devices that doesn't require a parent bus argument but 
provides a way to specify stable addressing (for instancing, using a 
linear index).

Regards,

Anthony Liguori