Patrick Mullaney wrote:
On Thu, 2009-04-02 at 16:27 +0300, Avi Kivity wrote:
virtio is a stable ABI.
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.
Sounds complicated...
IMO, it doesn't sound anymore complicated than making virtio support the
concepts already provided by vbus/venet-tap driver. Isn't there already
precedent for alternative approaches co-existing and having the users
decide which is the most appropriate for their use case? Switching
drivers in order to improve latency for a certain class of applications
would seem like something latency sensitive users would be more than
willing to do. I'd like to point out 2 things. Greg has offered help
in moving virtio into the vbus infrastructure. The vbus infrastructure
is a large part of what is being proposed here.
vbus (if I understand it right) is a whole package of things:
- a way to enumerate, discover, and manage devices
That part duplicates PCI and it would be pretty hard to convince me we
need to move to something new. virtio-pci (a) works, (b) works on Windows.
- a different way of doing interrupts
Again, the need to paravirtualize kills this on Windows (I think).
- a different ring layout, and splitting notifications from the ring
I don't see the huge win here
- placing the host part in the host kernel
Nothing vbus-specific here.
Switching drivers is unfortunately not easy on Linux as you need a new
kernel; it's easier on Windows once you have the drivers written.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
