[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

>>> On 26.08.13 at 17:37, Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
> On 8/26/2013 6:36 AM, Sander Eikelenboom wrote:
>>> >So as already suspected HPET and IVRS tables conflict with one
>>> >another in the IDs used for the (apparently) single HPET in the
>>> >system.
>> Yes that was wat i meant with another firmware glitch, masking the fact that 
> your fix seems actually ok.
> I have seen many issues with the IVRS table regarding IOAPIC. This is 
> the first time I see with the HPET, in which case, your patch simply So, 
> my understanding is the patch still does not solve the issue where the 
> IVRS and HPET table has conflicts here.  This means we should also have 
> the override mechanism for the HPET entry of the IVRS (i.e. the variety 
> 2 as well)?

Except that the override as is (coming from Linux) won't help afaict,
as it assumes that at least the ID is correct (and uses the ID to
associate the rest of the information with the right instance). Let
me get finished with the first draft of the ported over workaround
(hopefully tomorrow), and then we should discuss if/how to deal
with Sander's problem. But we shouldn't forget that he already
found out that enabling HPET MSI on his system isn't desirable due
to other errata, so in a way I'm inclined to leave this specific
unaddressed, thus not risking him to run into further problems
(with the patch sent earlier at least the stalls he saw went away,
albeit not in the way that was intended to happen).


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.