qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH, RFC 0/5] Improve device info handling
Date: Wed, 2 Sep 2009 20:53:01 +0300

On Wed, Sep 2, 2009 at 7:42 PM, Gerd Hoffmann<address@hidden> wrote:
>  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.

Then the "host" qdev does not make much sense, current tables should be fine.

> 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 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:  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.

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]