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

Jan


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