qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 5/7] vmxnet3: The vmxnet3 device is a PCIE en


From: Jason Wang
Subject: Re: [Qemu-devel] [PATCH v3 5/7] vmxnet3: The vmxnet3 device is a PCIE endpoint
Date: Tue, 15 Dec 2015 16:12:07 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0


On 12/15/2015 02:09 PM, Shmulik Ladkani wrote:
> Hi Jason,
>
> On Tue, 15 Dec 2015 10:35:59 +0800 Jason Wang <address@hidden> wrote:
>>> Another attempt I've made is to indroduce a new type vmxnet3e (the
>>> pcie variant of vmxnet3).
>>> I dropped this approach since it was way too cumbersome, introducing
>>> lots of boiler-plate code for the two (otherwise) identical types.
>> Yes, that's another solution (as I replied for patch 6). A question
>> here. If vmware differs pci-e version of vmxnet3 from pci version,
>> probably we need do the same (and you don't even need to care for
>> compatibility in the case). At a quick glance, no much duplicated codes.
>> (if you mean the msi offsets, you can let vmxnet3e use the new offset
>> unconditionally).
> Examples of duplicated boiler plate:
>
> Split to a TYPE_VMXNET3_BASE abstract type having two concrete sub types.
>
> Introduction of 'VMStateDescription vmstate_vmxnet3e' which differs only
> due to its '.name' (must be the name of the type, i.e "vmxnet3e") and
> the use of VMSTATE_PCIE_DEVICE (instead of VMSTATE_PCI_DEVICE), but
> otherwise idential to existing 'VMStateDescription vmstate_vmxnet3'.
>
> Introduction of 'VMStateDescription vmxstate_vmxnet3e_mcast_list' which
> differs only by '.name' (must be "vmxnet3e/mcast_list" instead of
> "vmxnet3/mcast_list") but otherwise identical to existing
> 'vmxstate_vmxnet3_mcast_list'.
>
> Also, the vmxnet3 device is indeed a PCIE, and should have been so since
> start.

Yes, so this is a strong reason that we must not introduce a new type.

> The reason we're keeping the non-pcie variant is not since user would be
> interested in an environment having the the non-pcie type, but only for
> not breaking migration from old hardware versions.
>
> Thus, suggesting 2 device types, providing the non-pcie variant as a
> user visible type, exposes the user with a choice of selecting a type
> which ideally shouldn't have existed at all.
> This seems less preferrable.
>
> Regards,
> Shmulik
>

I get the point, thanks for the clarification.





reply via email to

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