From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suravee Suthikulpanit 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 10:50:27 -0500 Message-ID: <521B7943.9030201@amd.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: multipart/mixed; boundary="===============3534864821005745530==" Return-path: In-Reply-To: <521B7624.4040604@amd.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Sander Eikelenboom Cc: Andrew Cooper , Jan Beulich , xen-devel List-Id: xen-devel@lists.xenproject.org --===============3534864821005745530== Content-Type: multipart/alternative; boundary="------------030404020109080503000201" --------------030404020109080503000201 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 8/26/2013 10:37 AM, 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)? > > Suravee > Nevermind, there is also the kernel option "ivrs_hpet" for that. Suravee --------------030404020109080503000201 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 8/26/2013 10:37 AM, 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)?

Suravee

Nevermind, there is also the kernel option "ivrs_hpet" for that.

Suravee



 --------------030404020109080503000201-- --===============3534864821005745530== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3534864821005745530==--