From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MisuZ-0001mv-Ie for qemu-devel@nongnu.org; Wed, 02 Sep 2009 12:42:19 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MisuU-0001hL-Fx for qemu-devel@nongnu.org; Wed, 02 Sep 2009 12:42:18 -0400 Received: from [199.232.76.173] (port=57270 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MisuU-0001h8-Bs for qemu-devel@nongnu.org; Wed, 02 Sep 2009 12:42:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19264) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MisuT-000577-N0 for qemu-devel@nongnu.org; Wed, 02 Sep 2009 12:42:14 -0400 Message-ID: <4A9EA05F.50100@redhat.com> Date: Wed, 02 Sep 2009 18:42:07 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH, RFC 0/5] Improve device info handling References: <4A9B85E5.8040902@redhat.com> <4A9CD334.6000407@redhat.com> <4A9E1247.9040009@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel Hi, >> The qdev root is the main_system_bus right now, I don't see a need to change >> that. All core devices (cpus, memory, pic, ...) can be children of the main >> system bus. > > That level is too low, because the metamachine level would not be > interested in the internals of the pc device (except generic > parameters like memory, number of CPUs etc), but how it connects to > the host devices. IMO the connection to the host device belongs to the guest device which needs the link. i.e. the scsi-disk driver should handle that, not some metamachine. >> We have to clearly separate between host state and guest state. >> qdev is about guest state. > > Yes, it's about guest state _now_, but why limit it to that? But if > host devices as a class are really different from guest device, we > could have something similar to qdev but for host devices. I still > don't see a need for a special type. There are a number of differences. guest devices belong to a emulated bus (ide/pci/usb/scsi/whatever). host devices don't. guest devices form a device tree. host devices are simple flat lists. It might make sense to create something simliar to qdev for the host devices. >> A disk has two sides: The host side (virtual drive foo is a lvm volume in >> raw format / a file in qcow2 format / a iso image / whatever else) and the >> guest side (this virtual drive is a master ide disk / scsi disk with id 3 / >> virtio disk / ...). Only the later is represented by qdev. The link >> between the two is a property. > > There is no need for a link. Instead of the property stuff, the pc > qdev should make available mappable objects (drive placeholders), The pc qdev doesn't know which "mappable objects" exist. The knowledge is scattered all over the devices (ide / scsi / virtio-blk / usb-storage / ...). And not all of them are present in all configurations. > the > metamachine would plug in the host drives by mapping the drive to a > host drive. It's just like device vs. address: drive placeholder vs. > host drive. It works the other way around: We have a linked list of host drives (with names). guest drives have a property, setting the property will lookup the host drive by name (only virtio-blk is merged, patches for scsi-disk & usb-storage are on the list). > Consider vlan: > DeviceState *gdev, *hdev, *vlan; > VLAN *gvlan, *hvlan; > > hdev = qdev_create(NULL, "host"); > qdev_init(hdev); > > gdev = qdev_create(NULL, "pc"); > qdev_init(gdev); > > vlan = qdev_create(NULL, "vlan"); > qdev_init(gdev); > gvlan = qdev_get_vlan_in(gdev, 0); // Analogous to gpio Same problem as with the drives: pc doesn't handle vlans, the nic driver somewhere down the device tree does. cheers, Gerd