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

Avi Kivity
2007-05-14T12:05:04Z

ron minnich wrote:
> We had hoped to get something like this into Xen. On Xen, for example,
> the block device and ethernet device interfaces are as different as
> one could imagine. Disk I/O does not steal pages from the guest. The
> network does. Disk I/O is in 4k chunks, period, with a bitmap
> describing which of the 8 512-byte subunits are being sent. The enet
> device, on read, returns a page with your packet, but also potentially
> containing bits of other domain's packets too. The interfaces are as
> dissimilar as they can be, and I see no reason for such a huge
> variance between what are basically read/write devices.
>

The reason for the variance is that hardware capabilities are very
different for disk and block. Block device requests are always
guest-initiated and sector-aligned, and often span many pages. On the
other hand, network packets are byte aligned, and rx packets are
host-initiated, triggering the stolen pages concept (which
unsurprisingly turned out not to be a win). Network has such esoteric
features as TSO. Block is very interested in actually getting things
onto the disk (barrier support).

In short, the "everything is a stream of bytes" grossly oversimplifies
things.

> Another issue is that kvm, in its current form (-24) is beautifully
> simple. These additions seem to detract from the beauty a bit. Might
> it be worth taking a little time to consider these ideas in order to
> preserve the basic elegance of KVM?
>

kvm? elegant and simple? it's basically a pile of special cases.

But I agree that the growing code base is a problem. With the block
driver we can probably keep the host side in userspace, but to do the
same for networking is much more work. I do think (now) that it is doable.

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