On Mon, Sep 21, 2015 at 11:23:03PM -0600, Jan Beulich wrote: > >>> Konrad Rzeszutek Wilk <konrad.w...@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 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel