Hi Jason, On Tue, 15 Dec 2015 10:35:59 +0800 Jason Wang <jasow...@redhat.com> 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. 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
