On Wed, Jun 14, 2023 at 01:20:47PM -0600, Alex Williamson wrote: > Regarding relaxed ordering, are we talking about the 'No RO-enabled > PR-PR Passing' bit in the devcap2 register? I don't think so.. The RO problem is that the RO bit in the config space is only defined for a SRIOV PF not a SRIOV VF. The VF wires 0 to that config space. So if you stick a VF into a VM as a vPCI then it appears to have a 0 RO bit in the config space. A VM driver that relies on it will think it is not enabled. I suppose atomic will have the same issue? > In general, I think we put driver writers in an awkward place if they > start trying things that are clearly not supported as reported by > hardware capability bits. If you start down this path then IMHO it all has to work the same for a VF and the VF has to inherent any relevant PF capability bits. This also means the vPCI emulated bits don't actually work correctly which is a different mess.. This is why the answer of "don't trust the config space" is appealing for driver writers because the VMMs are not able to emulate bare metal very well in these details. Jason
