Re: [PATCH] xen/mcfg: Call PHYSDEVOP_pci_mmcfg_reserved before PCI enumeration

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Mon, Sep 21, 2015 at 11:23:03PM -0600, Jan Beulich wrote:
> >>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 09/21/15 8:06 PM >>>
> >- Never figured out how much data we should save in the Xen's
> >struct pci_device to see if we are 'stale'. Looking back I think
> >we just need to do the interogation of the PCI capabilities and see
> >if they have somehow changed (the ones we care about).
> 
> Didn't we settle on no data to be needed here at all, instead requiring Dom0
> to report devices removed on buses about to be re-numbered, adding them
> back after the re-numbering?

Perhaps?

The Linux code constructs the structs for bus and pci devices (and dispatches
the hypercalls) as it walks the ACPI PCI bus. And if the reassign parameter was used
it then during this walk (buses first) alters the PCI_PRIMARY_BUS. Once it has
done that it restarts the walk and scans for the PCI devices.

What that means is that all the internal Linux PCI devices structure
devices are not available before this ACPI bus scan is done (while
the Xen PCI deviecs structures are available).

The best I could come up with is to do two loops:
 1) for 0:0:0 -> ff:ff:ff call PHYSDEVOP_pci_device_remove
    (so blow away what Xen has for its PCI devices.. except for the AMD IOMMU)
 2) list_for_each_pci_device PHYSDEVOP_pci_device_add (or other variants
    if VF).

But that is just a hack working around the Linux code.

My thinking was that why don't we just make PHYSDEVOP_pci_device_add be
capable of dealing with changes like these.

However, you  have also added the code to trap on PCI configuation access
we could also do some smarts when PCI_PRIMARY_BUS is modified (see
a88b72fddd046a0978242411276861039ec99ad0 x86/PCI: add config space abstract
write intercept logic). That would take care of it much easier I think?

> 
> Jan
>