From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [xen-unstable] Commit 2ca9fbd739b8a72b16dd790d0fff7b75f5488fb8 AMD IOMMU: allocate IRTE entries instead of using a static mapping, makes dom0 boot process stall several times. Date: Mon, 26 Aug 2013 16:50:41 +0100 Message-ID: <521B957102000078000EE818@nat28.tlf.novell.com> References: <1831656044.20130722225004@eikelenboom.it> <1182640844.20130816012228@eikelenboom.it> <33876223.20130816014116@eikelenboom.it> <520DEEFD02000078000EC76F@nat28.tlf.novell.com> <208201973.20130816094246@eikelenboom.it> <520DF8F302000078000EC7AD@nat28.tlf.novell.com> <1157392160.20130816104005@eikelenboom.it> <520E0AA002000078000EC82B@nat28.tlf.novell.com> <451541998.20130816124429@eikelenboom.it> <520E422602000078000EC94D@nat28.tlf.novell.com> <1834274604.20130823005128@eikelenboom.it> <52178DBB02000078000EE0BC@nat28.tlf.novell.com> <1636534211.20130823170508@eikelenboom.it> <521797B002000078000EE0F0@nat28.tlf.novell.com> <1864096999.20130823172907@eikelenboom.it> <521B18EC02000078000EE410@nat28.tlf.novell.com> <5710216193.20130826115151@eikelenboom.it> <521B4B0C02000078000EE51B@nat28.tlf.novell.com> <1971443098.20130826132159@eikelenboom.it> <521B582802000078000EE5AD@nat28.tlf.novell.com> <5210626005.20130826133612@eikelenboom.it> <521B7624.4040604@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <521B7624.4040604@amd.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Suravee Suthikulpanit Cc: Andrew Cooper , xen-devel , Sander Eikelenboom List-Id: xen-devel@lists.xenproject.org >>> On 26.08.13 at 17:37, Suravee Suthikulpanit wrote: > 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). Jan