|
From: | Gerd Hoffmann |
Subject: | Re: [Qemu-devel] [PATCH, RFC 0/5] Improve device info handling |
Date: | Wed, 02 Sep 2009 18:42:07 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Lightning/1.0pre Thunderbird/3.0b3 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |