Re: [Qemu-devel] [PATCH 7/7 v5] VMXNET3 paravirtualized device implementation Interface type "vmxnet3" added.

[Stefan Hajnoczi]

On Wed, Apr 11, 2012 at 2:53 PM, Daniel P. Berrange <address@hidden> wrote:
> On Tue, Apr 10, 2012 at 04:47:19PM +0100, 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
>> > 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.

I am not trying to change patch acceptance criteria.  I'm trying to
understand what problem the submitter is trying to solve with these
patches and how they intend to support them in the future.  And I'm
hoping to explain the risk of adding this feature to QEMU.

But as I said, I'm not strongly against them.  I'd just like some
discussion before merge.

Stefan