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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.04.13 at 18:14, Suravee Suthikulanit <suravee.suthikulpanit@xxxxxxx>
wrote:
> On 4/15/2013 9:43 AM, Jan Beulich wrote:
>>>>> On 13.04.13 at 03:16, Suravee Suthikulpanit 
>>>>> <suravee.suthikulpanit@xxxxxxx> 
> wrote:
>>> 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
>>> working.
>> 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'm just guessing that your USB controllers, other than the disk and
network ones (which apparently work), use pin based interrupts
rather than MSI.

>> 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.

Where did you spot that? To prevent this from happening is exactly
why amd_iommu_read_msi_from_ire() isn't empty anymore (this is
where the original MSI message information gets reconstructed - or
at least is intended to be). The only modification done by
update_intremap_entry_from_msi_msg() are the low 11 data bits,
and that's what gets overwritten upon read.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel