On Tue, Apr 10, 2012 at 04:47:19PM +0100, Stefan Hajnoczi wrote: > On Wed, Apr 4, 2012 at 12:44 PM, Izik Eidus > <izik.ei...@ravellosystems.com> wrote: > > What about this patch?, everything that was asked from Dmitry was > > accomplished... > > What prevent us from progressing with merging this patch? > > Hang on, I asked what the point of the VMware paravirt device models > is. I don't think that was ever answered fully. > > I know it makes migration of existing VMware guests easy, but now we > have the burden of maintaining these device models, whose feature set > and performance will never be equivalent to virtio. The reason is > because we cannot extend the device spec without breaking guests (we > don't control the device specification and therefore cannot add new > features) and we now have twice as much performance optimization work > if we want the same level of performance as virtio devices. > > For these reasons, I think that VMware device models can only ever be > 2nd class device models in QEMU. And I wonder if the effort isn't > better invested in good v2v migration tooling instead of adding this > to QEMU. > > I'm not strongly against VMware device models in QEMU, I do see the > benefit too, but please explain what the plan here is.
While I can sort of understand where you're coming from, this does seem to be inventing new patch acceptance criteria (which VMXNET3 authors have to satisfy) that haven't generally existed / been applied to any other device impl submission in the past. AFAICT, QEMU has welcomed / accepted patches implementing pretty much any hardware device, provided the code quality was acceptable. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|