On Tue, Jul 30, 2024 at 11:35:17AM -0600, Alex Williamson wrote: > Even if QEMU defines the layout for a device, there may be multiple > versions of that device. For example, maybe we just add PASID now, but > at some point we decide that we do want to replicate the PF serial > number capability. At that point we have versions of the device which > would need to be tied to versions of the machine and maybe also > selected via a profile switch on the device command line. This is the larger end state I see here. When the admin asks to install a vPCI function into a VM the admin would specify they want, say, 'virtio-net vPCI spec 1.0'. The text of spec 1.0 would specify each and every bit of config space and register layout. It would specify the content of the live migration blobs, and an exact feature set/behaviors the device must advertise. Even if the device can do more, a combination of the VMM and the variant PCI driver+device FW would make it do only what spec 1.0 says it should do. You can imagine there would be a range of these standards available, and large sites have a high chance to have their own private forks. This should be viewed as totally opposite the current VFIO behavior that intends to reflect the exact device, as-is, into the VM. I think we can reasonably have different approaches to each. So, how we manage this as an ecosystem, I don't know. It sure would be nice to not need kernel changes to push through a new virtual device spec! But I think your summary is good. Thanks, Jason
