Avi Kivity wrote:
Gregory Haskins wrote:That doesnt make sense to me, tho. All the testing I did was a UP
Rusty Russell wrote:I think Rusty did mean a UP guest, and without schedule-and-forget.
On Thursday 02 April 2009 21:36:07 Gregory Haskins wrote:I assume you mean UP host ;)
You do not need to know when the packet is copied (which I currentlyBut if you have a UP guest,
do). You only need it for zero-copy (of which I would like to
support,
but as I understand it there are problems with the reliability of
proper
callback (i.e. skb->destructor).
guest, actually. Why would I be constrained to run without the
scheduling unless the host was also UP?
The problem is that we already have virtio guest drivers going several
kernel versions back, as well as Windows drivers. We can't keep
changing the infrastructure under people's feet.
Well, IIUC the virtio code itself declares the ABI as unstable, so there
technically *is* an out if we really wanted one. But I certainly
understand the desire to not change this ABI if at all possible, and
thus the resistance here.
However, theres still the possibility we can make this work in an ABI
friendly way with cap-bits, or other such features. For instance, the
virtio-net driver could register both with pci and vbus-proxy and
instantiate a device with a slightly different ops structure for each or
something. Alternatively we could write a host-side shim to expose vbus
devices as pci devices or something like that.