On 11/21/19 8:08 PM, Alex Williamson wrote:
On Thu, 21 Nov 2019 19:19:13 -0300 Daniel Henrique Barboza <danielhb413@gmail.com> wrote:
[...]
My question is: should Libvirt force function 0 to be present in boot time as well, regardless of whether the PPC64 guest or some cards are able to boot without it?
In my reading of the PCI 3.0 spec, 3.2.2.3.4 indicates that multifunction devices are required to implement function 0 and that configuration software is under no obligation to scan for higher number functions if function 0 is not present and does not have the multifunction bit set in the header type register. With PCIe, where link information, payload size, ARI, VC, etc are exposed in config space, many of these are only valid or have specific means only for function 0.
What you're seeing on PPC is, I think, more typical of paravirtualized PCI enumeration, where you're only seeing a view of the bus as allowed by a hypervisor. I can't say whether the pcie_scan_all boot option was added to allow discovery of devices as in your configuration or simply to correct cases where function 0 forgot to implement the multifunction
Just checked. Neither the Power 8 host nor the guest is booting with the pcie_scan_all option.
bit.Whether libvirt wants to prevent this is more of a support question, it seems spec compliant hardware should never do this, but not all hardware is spec compliant. Libvirt should never generate such a configuration on it's own, but I wouldn't necessarily object if it allows a user to shoot themselves in the foot. Thanks,
I am not so thrilled about it after what you said. It seems that the PPC64 guest is behaving differently from all other archs in this case, and I'd rather make PPC64 equal to everyone else rather than allowing the PPC64 user to expect that non-compliant behavior is allowed. Thanks, DHB
Alex