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

[Avi Kivity <avi@qumranet.com>]

arnd@arndb.de wrote:

> This adds a new bus_type for virtio that is intended to
> be completely agnostic of the underlying host transport
> and the upper-level protocol.
>
> Device drivers and host drivers register here, and operations
> are provided that let a device driver talk to the device
> emulation in the hypervisor without knowing the kind of hypervisor.
> Module autoloading through udev should also work.
>
> Loosely based on Rusty's Virtio draft III.
> +
> +/**
> + * virtio_device_id - match a virtio device to a driver
> + * @device_type: string identifying the virtio interface.
> + * @driver_data: used internally by the driver.
> + */
> +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?

> +
> +/**
> + * virtio_config - virtual device configuration.
> + * @host: structured data interpreted by the host driver.
> + * @driver: structured data interpreted by the device driver.
> + *
> + * The configuration space is what gets used to tell a driver
> + * about the device, e.g. MAC address or block device size.
> + * All fields in here are read-only in the virtual machine,
> + * they are set up by the host.
> + *
> + * The host part remains opaque to the device driver, it can
> + * contain e.g. lguest device index numbers or part of a PCI
> + * configuration space.
> + *
> + * The 256 bytes total intentionally match the size of the
> + * legacy PCI config registers, but the driver should not
> + * expect the layout to be derived from PCI.
> + *
> + * Every virtio_driver should define a data structure for the
> + * virtio_config->driver data, which becomes part of its ABI.
> + */
> +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.


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.

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