From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Miu1T-0006gf-9v for qemu-devel@nongnu.org; Wed, 02 Sep 2009 13:53:31 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Miu1O-0006gE-Hl for qemu-devel@nongnu.org; Wed, 02 Sep 2009 13:53:30 -0400 Received: from [199.232.76.173] (port=43734 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Miu1O-0006g3-Dv for qemu-devel@nongnu.org; Wed, 02 Sep 2009 13:53:26 -0400 Received: from mail-ew0-f223.google.com ([209.85.219.223]:39677) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Miu1N-0008Ol-LA for qemu-devel@nongnu.org; Wed, 02 Sep 2009 13:53:25 -0400 Received: by ewy23 with SMTP id 23so1131636ewy.8 for ; Wed, 02 Sep 2009 10:53:24 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4A9EA05F.50100@redhat.com> References: <4A9B85E5.8040902@redhat.com> <4A9CD334.6000407@redhat.com> <4A9E1247.9040009@redhat.com> <4A9EA05F.50100@redhat.com> From: Blue Swirl Date: Wed, 2 Sep 2009 20:53:01 +0300 Message-ID: Subject: Re: [Qemu-devel] [PATCH, RFC 0/5] Improve device info handling 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: Gerd Hoffmann Cc: qemu-devel On Wed, Sep 2, 2009 at 7:42 PM, Gerd Hoffmann wrote: > =C2=A0Hi, > >>> The qdev root is the main_system_bus right now, I don't see a need to >>> change >>> that. =C2=A0All core devices (cpus, memory, pic, ...) can be children o= f 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. =C2=A0i.e. the scsi-disk driver should handle that, not s= ome > 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. =C2=A0guest devices belong to a emulat= ed bus > (ide/pci/usb/scsi/whatever). =C2=A0host devices don't. =C2=A0guest device= s form a > device tree. =C2=A0host devices are simple flat lists. Then the "host" qdev does not make much sense, current tables should be fin= e. > It might make sense to create something simliar to qdev for the host > devices. > >>> A disk has two sides: =C2=A0The host side (virtual drive foo is a lvm v= olume >>> 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 / ...). =C2=A0Only the later is represented by qdev. =C2=A0= 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. =C2=A0The knowle= dge is > scattered all over the devices (ide / scsi / virtio-blk / usb-storage / > ...). =C2=A0And not all of them are present in all configurations. The metamachine could scan the device tree using the future qdev classes, but I didn't want that the metamachine messes with the internals of pc qdev. It also seems artificial to float the knowledge upwards. >> 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: =C2=A0We have a linked list of host drives= (with > names). =C2=A0guest drives have a property, setting the property will loo= kup the > host drive by name (only virtio-blk is merged, patches for scsi-disk & > usb-storage are on the list). > >> Consider vlan: >> =C2=A0 =C2=A0DeviceState *gdev, *hdev, *vlan; >> =C2=A0 =C2=A0VLAN *gvlan, *hvlan; >> >> =C2=A0 =C2=A0hdev =3D qdev_create(NULL, "host"); >> =C2=A0 =C2=A0qdev_init(hdev); >> >> =C2=A0 =C2=A0gdev =3D qdev_create(NULL, "pc"); >> =C2=A0 =C2=A0qdev_init(gdev); >> >> =C2=A0 =C2=A0vlan =3D qdev_create(NULL, "vlan"); >> =C2=A0 =C2=A0qdev_init(gdev); >> =C2=A0 =C2=A0gvlan =3D 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. There is still the reset signal case, monitor and displays. Reset could be equally well handled by leaf devices instead of top of the tree. Monitor could use host char devices, like it does now. Host display devices can be grabbed by VGA etc. So in summary I think my top-down approach is not very optimal.