Re: [Xen-devel] [xen-unstable] Commit 2ca9fbd739b8a72b16dd790d0fff7b75f5488fb8 AMD IOMMU: allocate IRTE entries instead of using a static mapping, makes dom0 boot process stall several times.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.08.13 at 13:21, Sander Eikelenboom <linux@xxxxxxxxxxxxxx> wrote:

> Monday, August 26, 2013, 12:33:16 PM, you wrote:
> 
>>>>> On 26.08.13 at 11:51, Sander Eikelenboom <linux@xxxxxxxxxxxxxx> wrote:
>>> Monday, August 26, 2013, 8:59:24 AM, you wrote:
>>>> It also alters a bogus comparison in the original code (note the
>>>> extra ! in (!msi_desc->hpet_id != hpet_sbdf.id)) - I can't see why
>>>> it would have been coded that way, but double checking the
>>>> output with "iommu=debug" for the absence of the respective
>>>> message would be very helpful.
>>> 
>>> With the patch below i end up with:
>>> 
>>> (XEN) [2013-08-26 09:42:53] AMD-Vi: Failed to setup HPET MSI remapping: 
>>> Wrong 
>>> HPET  msi_desc->hpet_id: 0x2  hpet_sbdf.id: 0
>>> (XEN) [2013-08-26 09:42:53] AMD-Vi: Failed to setup HPET MSI remapping: 
>>> Wrong 
>>> HPET  msi_desc->hpet_id: 0x2  hpet_sbdf.id: 0
>>> (XEN) [2013-08-26 09:42:53] AMD-Vi: Failed to setup HPET MSI remapping: 
>>> Wrong 
>>> HPET  msi_desc->hpet_id: 0x2  hpet_sbdf.id: 0
> 
>> So that's exactly the bogus comparison mentioned above. And
>> you say that you do have working HPET MSI on the native kernel,
>> without any extra overrides? I ask because I don't see any
>> workarounds for apparently broken firmware like here...
> 
>> To be sure it's the firmware, could you
>> - send the dump of the ACPI HPET table
>> - try restoring the bogus "!"
> 
> acpidump attached ..

So as already suspected HPET and IVRS tables conflict with one
another in the IDs used for the (apparently) single HPET in the
system.

Jan


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