Re: [PATCH/RFC 7/9] Virtual network guest device driver

Arnd Bergmann
2007-05-21T11:28:03Z

On Monday 21 May 2007, Christian Borntraeger wrote:
> > This is quite easy with KVM.  I like the approach that vmchannel has
> > taken.  A simple PCI device.  That gives you a discovery mechanism for
> > shared memory and an interrupt and then you can just implement a ring
> > queue using those mechanisms (along with a PIO port for signaling from
> > the guest to the host).  So given that underlying mechanism, the
> > question is how to expose that within the guest kernel/userspace and
> > within the host.
>
> Sorry for answering late, but I dont like PCI as a device bus for all
> platforms. s390 has no PCI and s390 has no PIO. I would prefer a new
> simple hypercall based virtual bus. I dont know much about windows
> driver programming, but I guess it it is not that hard to add a new bus.

We've had the same discussion about PCI as virtual device abstraction
recently when hpa made the suggestions to get a set of PCI device
numbers registered for Linux.

IIRC, the conclusion to which we came was that it is indeed helpful
for most architecture to have a PCI device as one way to probe for
the functionality, but not to rely on it. s390 is the obvious
example where you can't have PCI, but you may also want to build
a guest kernel without PCI support because of space constraints
in a many-guests machine.

What I think would be ideal is to have a new bus type in Linux
that does not have any dependency on PCI itself, but can be
easily implemented as a child of a PCI device.

If we only need the stuff mentioned by Anthony, the interface could
look like

struct vmchannel_device {
struct resource virt_mem;
struct vm_device_id id;
int irq;
int (*signal)(struct vmchannel_device *);
int (*irq_ack)(struct vmchannel_device *);
struct device dev;
};

Such a device can easily be provided as a child of a PCI device,
or as something that is purely virtual based on an hcall interface.