[libvirt] [PATCH v2 0/4] PCI hostdev partial assignment support

[Daniel Henrique Barboza]

On 11/21/19 8:08 PM, Alex Williamson wrote:
> On Thu, 21 Nov 2019 19:19:13 -0300
> Daniel Henrique Barboza <danielhb413 at 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
>