Michael S. Tsirkin wrote: > On Mon, Aug 17, 2009 at 10:14:56AM -0400, Gregory Haskins wrote: >> Case in point: Take an upstream kernel and you can modprobe the >> vbus-pcibridge in and virtio devices will work over that transport >> unmodified. >> >> See http://lkml.org/lkml/2009/8/6/244 for details. > > The modprobe you are talking about would need > to be done in guest kernel, correct? Yes, and your point is? "unmodified" (pardon the psuedo pun) modifies "virtio", not "guest". It means you can take an off-the-shelf kernel with off-the-shelf virtio (ala distro-kernel) and modprobe vbus-pcibridge and get alacrityvm acceleration. It is not a design goal of mine to forbid the loading of a new driver, so I am ok with that requirement. > >> OTOH, Michael's patch is purely targeted at improving virtio-net on kvm, >> and its likewise constrained by various limitations of that decision >> (such as its reliance of the PCI model, and the kvm memory scheme). > > vhost is actually not related to PCI in any way. It simply leaves all > setup for userspace to do. And the memory scheme was intentionally > separated from kvm so that it can easily support e.g. lguest. > I think you have missed my point. I mean that vhost requires a separate bus-model (ala qemu-pci). And no, your memory scheme is not separated, at least, not very well. It still assumes memory-regions and copy_to_user(), which is very kvm-esque. Vbus has people using things like userspace containers (no regions), and physical hardware (dma controllers, so no regions or copy_to_user) so your scheme quickly falls apart once you get away from KVM. Don't get me wrong: That design may have its place. Perhaps you only care about fixing KVM, which is a perfectly acceptable strategy. Its just not a strategy that I think is the best approach. Essentially you are promoting the proliferation of competing backends, and I am trying to unify them (which is ironic that this thread started with concerns I was fragmenting things ;). The bottom line is, you have a simpler solution that is more finely targeted at KVM and virtio-networking. It fixes probably a lot of problems with the existing implementation, but it still has limitations. OTOH, what I am promoting is more complex, but more flexible. That is the tradeoff. You can't have both ;) So do not for one second think that what you implemented is equivalent, because they are not. In fact, I believe I warned you about this potential problem when you decided to implement your own version. I think I said something to the effect of "you will either have a subset of functionality, or you will ultimately reinvent what I did". Right now you are in the subset phase. Perhaps someday you will be in the complete-reinvent phase. Why you wanted to go that route when I had already worked though the issues is something perhaps only you will ever know, but I'm sure you had your reasons. But do note you could have saved yourself grief by reusing my already implemented and tested variant, as I politely offered to work with you on making it meet your needs. Kind Regards -Greg
Attachment:
signature.asc
Description: OpenPGP digital signature
