On Wed, Apr 29, 2020 at 5:51 PM Cédric Le Goater <c...@kaod.org> wrote: > > When a passthrough IO adapter is removed from a pseries machine using > hash MMU and the XIVE interrupt mode, the POWER hypervisor, pHyp, > expects the guest OS to have cleared all page table entries related to > the adapter. If some are still present, the RTAS call which isolates > the PCI slot returns error 9001 "valid outstanding translations" and > the removal of the IO adapter fails. > > INTx interrupt numbers need special care because Linux maps the > interrupts automatically in the Linux interrupt number space if they > are presented in the device tree node describing the IO adapter. These > interrupts are not un-mapped automatically and in case of an hot-plug > adapter, the PCI hot-plug layer needs to handle the cleanup to make > sure that all the page table entries of the XIVE ESB pages are > cleared. > > Cc: "Oliver O'Halloran" <ooh...@gmail.com> > Signed-off-by: Cédric Le Goater <c...@kaod.org> > --- > arch/powerpc/kernel/pci-hotplug.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/powerpc/kernel/pci-hotplug.c > b/arch/powerpc/kernel/pci-hotplug.c > index bf83f76563a3..9e9c6befd7ea 100644 > --- a/arch/powerpc/kernel/pci-hotplug.c > +++ b/arch/powerpc/kernel/pci-hotplug.c > @@ -57,6 +57,8 @@ void pcibios_release_device(struct pci_dev *dev) > struct pci_controller *phb = pci_bus_to_host(dev->bus); > struct pci_dn *pdn = pci_get_pdn(dev); > > + irq_dispose_mapping(dev->irq);
What does the original mapping? Powerpc arch code or the PCI core? Tearing down the mapping in pcibios_release_device() seems a bit fishy to me since the PCI core has already torn down the device state at that point. If the release is delayed it's possible that another pci_dev has mapped the IRQ before we get here, but maybe that's ok. > + > eeh_remove_device(dev); > > if (phb->controller_ops.release_device) > -- > 2.25.4 >
