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

[Arnd Bergmann <arnd@arndb.de>]

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.

> > +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, 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.

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

	Arnd <><