Re: [RFC 1/4] New virtio bus driver

[Avi Kivity <avi@qumranet.com>]

Arnd Bergmann wrote:
> On Sunday 08 July 2007, Avi Kivity wrote:
>   
>> arnd@arndb.de wrote:
>>     
>
>   
>>> +struct virtio_device_id {
>>> +	const char *device_type;
>>> +	unsigned long driver_data;
>>> +};
>>>   
>>>       
>> Carrying a string through a hypervisor interface can be unpleasant.  How 
>> about a constant instead?
>>     
>
> I chose a string because I found it to work rather well on
> open firmware and on the platform bus. It probably has
> to be a fixed length string which will be sent down from
> the hypervisor along with all the device specific data.
>
>   

Fixed length strings are okay, though unlovely.

>>> +struct virtio_config {
>>> +	const char host[128];
>>> +	const char driver[128];
>>> +};
>>>   
>>>       
>> There needs to be a way for the driver to tell the device that 
>> configuration has changed (promiscuous mode, MAC address) and vice versa 
>> (media detect).
>>
>> Maybe have a configuration virtqueue for that.
>>     
>
> I was hoping that we can live without dynamic configuration data
> in the common case. For a simple point-to-point ethernet device,
> that should work fine, 

Well, once you have _one_ dynamic config, you need a mechanism.  So 
consider a disk change notification for block device.

> and more complicated devices might need their
> own interface, e.g. by embedding a command number in every
> chunk of data that is sent down the one virtqueue, or by having
> a separate virtqueue for all out-of-band data.
>
> Alternatively, we could have a mechanism separate from the
> virtqueue concept, like a synchronous get_config_data/set_config_data
> callback into the host driver.
>   

You also need to allow the host to notify the guest about configuration 
changes.

>   
>> What I'm missing here is the lego approach, where you can mix and match:
>>
>>   virtnet.ko: basic net driver atop virtio, not linked to any implementation
>>   virtio-lguest.ko, virtio-kvm.ko, virtio-xen.ko:  virtio transports
>>   virtbus-pci.ko, virtbus-vio.ko, virtbus-xen.ko: virtual configuration 
>> space handlers; responsible for creating queues
>>
>>   vnet-kvm-pci.ko, vnet-kvm-virtbus.ko: stub drivers that glue the 
>> components together
>>
>> So we'd have one 10-line driver for every combination.
>>     
>
> The whole point of the bus abstraction is that the device driver (virtnet
> in this case) does not care about the underlying transport at all,
> while the host driver does not care about the device.
>
> So in your example, you get
>
> virtnet.ko (, virtblock.ko, hwrng-virtio.ko, ...): host-independent
>   device driver
> virtbus-lguest.ko, virtbus-kvm.ko, virtbus-pci.ko, virtbus-xen.ko:
>   device independent host drivers
>
> In cases where some of the code can be shared, e.g. virtbus-lguest
> and virtbus-kvm, you can have multiple host drivers sharing part
> of their code by using symbols from a library module, but my basic
> idea is that each host driver has a single module that handles
> the transport and the device probing.
>   

Is that module linked to both the pci libraries and the virtbus 
libraries?  Or does virtbus abstract pci in some way?


-- 
error compiling committee.c: too many arguments to function