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.

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Friday, August 23, 2013, 6:01:33 PM, you wrote:

>>>> On 23.08.13 at 17:48, Sander Eikelenboom <linux@xxxxxxxxxxxxxx> wrote:

>> Friday, August 23, 2013, 5:21:26 PM, you wrote:
>> 
>>>>>> On 23.08.13 at 17:11, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>>>>>>> On 23.08.13 at 17:05, Sander Eikelenboom <linux@xxxxxxxxxxxxxx> wrote:
>>>> 
>>>>> Friday, August 23, 2013, 4:28:43 PM, you wrote:
>>>>> 
>>>>>>>>> On 23.08.13 at 00:51, Sander Eikelenboom <linux@xxxxxxxxxxxxxx> wrote:
>>>>>>> After i got things working on baremetal Linux, i adjusted Xen and 
>>>>>>> hardcoded 
>>>>>>> it to add a mapping for ioapic[6]=00:14.0.
>>>>>>> (the entries for ivrs_ioapic[7] and hpet[0] are actually correct in the 
>>>>>>> bios 
>> 
>>>> 
>>>>> 
>>>>>>> tables, so they don't need correction for me at the moment)
>>>>> 
>>>>>> Are you sure about the HPET part of this? I ask because that being
>>>>>> wrong could be an explanation for the stalls you see when using
>>>>>> cpuidle (as that could mean those HPET interrupts needed for
>>>>>> waking CPUs don't arrive).
>>>>> 
>>>>>> Speaking of which - why don't you try whether when not using
>>>>>> FSB-capable HPET channels, the stalls go away? All you'd need
>>>>>> to change is hpet_fsb_cap_lookup() - it ought to return without
>>>>>> doing anything (i.e., if you look at the code, as if
>>>>>> acpi_gbl_FADT.boot_flags had ACPI_FADT_NO_MSI set).
>>>>> 
>>>>> Ok adding:
>>>>> 
>>>>> @@ -392,6 +392,9 @@ static void __init hpet_fsb_cap_lookup(void)
>>>>>      u32 id;
>>>>>      unsigned int i, num_chs;
>>>>> 
>>>>> +    printk(XENLOG_INFO "SEIK HPET: return as if acpi_gbl_FADT.boot_flags 
>>>>> & 
>>>>> ACPI_FADT_NO_MSI\n");
>>>>> +    return;
>>>>> +
>>>>>      if ( unlikely(acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_MSI) )
>>>>>          return;
>>>>> 
>>>>> 
>>>>> Indeed made the stalls go away ..
>>>> 
>>>> So if this time you didn't leave a no-cpuidle in place somewhere ;-)
>>>> this makes relatively clear that the stalls are due to the interrupts
>>>> coming from the HPET not reaching their destinations. I still can't
>>>> connect this to the $subject commit yet, though.
>> 
>>> Could you provide 'M' and 'V' output for the bad (stalling) case?
>> 
>> Could it be some priority fight / locking issue with some other MSI(X) 
>> enabled devices.
>> (which happen to be the pci-e and ... the SATA controller ... and the 
>> Ethernet controllers)

> I don't think so. The logs you sent before this mail are interesting
> though - at a first glance there appear to be missing two out of the
> three IRTEs supposedly associated with the three HPET channels.
> And _that_ of course can be related to them now getting allocated
> instead of their offsets being derived from vector and delivery mode.

> I'll have to look deeper, but for the moment I'm trying to implement
> that IO-APIC/HPET override thing.

Ok thx, would have been nice if Suravee had perhaps indicated it's existence in 
Linux .. i just stumbled upon it by accident.
If you would like me to run some more debug patches that could provide you with 
the info in a easier way .. feel free to send


> Jan




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