[PATCH 2/3] powerpc/pci: unmap legacy INTx interrupts of passthrough IO adapters
Cédric Le Goater
clg at kaod.org
Wed May 27 17:31:58 AEST 2020
On 5/27/20 2:57 AM, Oliver O'Halloran wrote:
> On Wed, Apr 29, 2020 at 5:51 PM Cédric Le Goater <clg at 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" <oohall at gmail.com>
>> Signed-off-by: Cédric Le Goater <clg at 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?
Powerpc. In pci_read_irq_line() when a device is added.
> 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.
Which scenario would that be ? multiple devices mapping the same INTx
interrupt because all are used already ?
Where should we drop the mapping ?
Thanks,
C.
>> +
>> eeh_remove_device(dev);
>>
>> if (phb->controller_ops.release_device)
>> --
>> 2.25.4
>>
More information about the Linuxppc-dev
mailing list