[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 0/3] x86/IOMMU: multi-vector MSI prerequisites

On 4/15/2013 9:43 AM, Jan Beulich wrote:
On 13.04.13 at 03:16, Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx> 
On 4/12/2013 5:18 AM, Jan Beulich wrote:
1: IOMMU: allow MSI message to IRTE propagation to fail
2: AMD IOMMU: allocate IRTE entries instead of using a static mapping
3: AMD IOMMU: untie remap and vector maps

See the individual patches for what, if anything, has changed from v2.

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
This patch setfix the previous issue we sawfrom the get_intremap_entry()
causing the ASSERT on (table != NULL).  Now the system is booting.

However, I think there are some issues with the interrupt remapping for
the USBdevices. During dom0 booting, it gave error w/ regarding timeout
during loadingsome USB drivers. Also, lsmodis showing "hid_generic"
module is missing. This resulting in the USBmouse and keyboard are not
So I would guess something must be wrong with the IO-APIC
related code paths then.
Why is this IO-APIC and not MSI or MSIx?

I just went through them again, but the
only thing I spotted was a pointless duplicate assignment to
ioapic_sbdf[].pin_2_idx[] in amd_iommu_setup_ioapic_remapping().
Sadly we don't have the 'V' debug key for AMD yet, otherwise the
combination of 'V' and 'z' output would likely tell us quite clearly
what's wrong. Looking at 'z' might still be worthwhile though...



On another topic, in arch/x86/msi.c, in the function "setup_msi_affinity()", the code does:
1. "read_msi_msg"
2. Modify the affitity mask
3. "write_msi_msg" back the register value.

In read, if the interrupt remapping is enabled, from the patch, the function returns the MSI data with remapped information from IOMMU. Then in write, if the interrupt remapping is enabled, the function will update the IOMMU interrupt remapping entries with the already "remapped" vector. In this case, you would be updating the incorrect IOMMU IRTE.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.