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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.03.13 at 06:45, Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
wrote:
> On 3/29/2013 12:18 AM, Suravee Suthikulpanit wrote:
>> Jan,
>>
>> I found an issue when booting the hypervisor after the patch with 
>> assertion at the line 64 of iommu_intr.c (in function 
>> get_intremap_entry).
>>
>> Stack dump:
>> ...........
>> get_intremap_entry+0x39/0x58
>> amd_iommu_read_msi_from_ire+0x74/0xac
>> iommu_read_msi_from_ire+0x3c/0x3f
>> set_msi_affinity+0x161/0x1ae
>> enable_iommu+0x681/0x7d2
>> amd_iommu_init+0x50b/0x6b1
>> amd_iov_detect+0x69/0xad
>> iommu_setup+0x67/0x171
>> __start_xen+0x278c/0x2b9d
>>
>> ************************************
>> Panic on CPU 0:
>> Assertion '(table != NULL) && (offset < INTREMAP_ENTRIES)' failed at 
>> iommu_intr.c:64
>>
>> *************************************
>>
>> Investigation showing table is not null and offset = 0.
>>
> Sorry for typo.  The investigation shows that the ASSERT inside the 
> get_int_remap_entry failed when bdf = 0x2 (which is the IOMMU), the 
> table is NULL.

That's odd - even before the patch, exactly the same is being done
in update_intremap_entry_from_msi_msg(), yet the assertion didn't
trigger. Could you provide a full log with "iommu=debug" in place?
Perhaps with v2 of patch 3 in this series that I just sent as reply to
that other mail, as I spotted another bug while looking into this - the
"offset" parameter of {get,free}_intremap_entry() changed its
meaning from being a byte offset to being an entry one?

Jan


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