Re: [Qemu-devel] [PATCH, RFC 0/5] Improve device info handling

[Gerd Hoffmann <kraxel@redhat.com>]

   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