[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 7/7 v5] VMXNET3 paravirtualized device implement

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 7/7 v5] VMXNET3 paravirtualized device implementation Interface type "vmxnet3" added.
Date: Wed, 11 Apr 2012 12:27:07 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0

On 04/10/2012 10:47 AM, Stefan Hajnoczi wrote:
On Wed, Apr 4, 2012 at 12:44 PM, Izik Eidus
<address@hidden>  wrote:
What about this patch?, everything that was asked from Dmitry was
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.

As long as the code is high quality and there's a test suite to go along with it, I think adding additional device emulation is perfectly fine.

I don't think *inventing* new paravirtual devices is a good idea but this is just like someone submitting BNX emulation. Emulating a wide variety of devices is what we do.


Anthony Liguori

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]