On 11/21/19 8:08 PM, Alex Williamson wrote:
On Thu, 21 Nov 2019 19:19:13 -0300
Daniel Henrique Barboza <danielhb413@xxxxxxxxx> 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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
