ACK: [SRU][N/P][PATCH 0/1] kvmppc_set_passthru_irq_hv: Could not assign IRQ map traces are seen when pci device is attached to kvm guest when "xive=off" is set (LP: #2109951)

Thibault Ferrante thibault.ferrante at canonical.com
Wed Jun 11 09:28:00 UTC 2025


Acked-by: Thibault Ferrante <thibault.ferrante at canonical.com>


On 06/06/2025 16:34, Massimiliano Pellizzer wrote:
> BugLink: https://bugs.launchpad.net/bugs/2109951
> 
> [Impact]
> 
> KVM: PPC: Book3S HV: Fix IRQ map warnings with XICS on pSeries KVM Guest
> 
> The commit 9576730d0e6e ("KVM: PPC: select IRQ_BYPASS_MANAGER") enabled
> IRQ_BYPASS_MANAGER when CONFIG_KVM was set. Subsequently, commit
> c57875f5f9be ("KVM: PPC: Book3S HV: Enable IRQ bypass") enabled IRQ
> bypass and added the necessary callbacks to create/remove the mappings
> between host real IRQ and the guest GSI.
> 
> The availability of IRQ bypass is determined by the arch-specific
> function kvm_arch_has_irq_bypass(), which invokes
> kvmppc_irq_bypass_add_producer_hv(). This function, in turn, calls
> kvmppc_set_passthru_irq_hv() to create a mapping in the passthrough IRQ
> map, associating a host IRQ to a guest GSI.
> 
> However, when a pSeries KVM guest (L2) is booted within an LPAR (L1)
> with the kernel boot parameter `xive=off`, it defaults to using emulated
> XICS controller. As an attempt to establish host IRQ to guest GSI
> mappings via kvmppc_set_passthru_irq() on a PCI device hotplug
> (passhthrough) operation fail, returning -ENOENT. This failure occurs
> because only interrupts with EOI operations handled through OPAL calls
> (verified via is_pnv_opal_msi()) are currently supported.
> 
> These mapping failures lead to below repeated warnings in the L1 host:
> 
>   [  509.220349] kvmppc_set_passthru_irq_hv: Could not assign IRQ map for
> (58,4970)
>   [  509.220368] kvmppc_set_passthru_irq (irq 58, gsi 4970) fails: -2
>   [  509.220376] vfio-pci 0015:01:00.0: irq bypass producer (token
> 0000000090bc635b) registration fails: -2
>   ...
>   [  509.291781] vfio-pci 0015:01:00.0: irq bypass producer (token
> 000000003822eed8) registration fails: -2
> 
> Fix this by restricting IRQ bypass enablement on pSeries systems by
> making the IRQ bypass callbacks unavailable when running on pSeries
> platform.
> 
> [Fix]
> 
> Backport from mainline:
> - ccdb36cbe65f KVM: PPC: Book3S HV: Fix IRQ map warnings with XICS on pSeries
> KVM Guest
> 
> [Test Plan]
> 
> The issue can be tested executing the following steps:
> 
> 1. Start a guest with kernel
> 2. unbind the pci device from host using below command
> 
> root at ltcrain8og-lp6:~/NET# virsh nodedev-detach pci_0028_01_00_0
> Device pci_0028_01_00_0 detached
> root at ltcrain8og-lp6:~/NET# virsh nodedev-detach pci_0028_01_00_1
> Device pci_0028_01_00_1 detached
> 
> 3. Now attach the pci device to guest using virsh attach-device command. The xml
> snippet used is given below
> 
> root at ltcrain8og-lp6:~/NET# vi pci2.xml
> <hostdev mode='subsystem' type='pci' managed='yes'>
>    <source>
>      <address domain='0x0028' bus='0x01' slot='0x00' function='0x0'/>
>    </source>
> </hostdev>
> 
> root at ltcrain8og-lp6:~/NET# virsh attach-device vm pci2.xml
> Device attached successfully
> 
> 4. Verify that on guest side the pci device gets attached successfully, and the
> interface comes up. Moreover, check that the kernel ring buffer does not show
> any error of the following type:
> 
> [57906.347794] kvmppc_set_passthru_irq_hv: Could not assign IRQ map for
> (100,4900)
> [57906.347812] kvmppc_set_passthru_irq (irq 100, gsi 4900) fails: -2
> [57906.347817] vfio-pci 0028:01:00.0: irq bypass producer (token
> 00000000c84b35a9) registration fails: -2
> 
> [Where Problems Could Occur]
> 
> The fix affects the IRQ bypass infrastructure in the PowerPC KVM hypervisor,
> specifically the initialization of architecture-specific callback handlers for
> IRQ passthrough. An issue with this fix may introduce problems such as the VFIO
> subsystem failing to handle IRQ bypass even on capable PowerNV systems.
> 
> [Other Info]
> 
> Oracular not patched because EOL.
> 




More information about the kernel-team mailing list