From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH 3/3] x86/AMD-Vi: Fix IVRS HPET special->handle override Date: Mon, 23 Sep 2013 18:03:20 +0100 Message-ID: <52407458.9000505@citrix.com> References: <1379115031-1992-1-git-send-email-suravee.suthikulpanit@amd.com> <1379115031-1992-4-git-send-email-suravee.suthikulpanit@amd.com> <5236D75E02000078000F3847@nat28.tlf.novell.com> <523862B8.8000207@amd.com> <523891C902000078000F4070@nat28.tlf.novell.com> <523CC05C.7030903@amd.com> <5240014202000078000F555E@nat28.tlf.novell.com> <524070E8.8000900@amd.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1739170282363379294==" Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VO9Xh-0003CE-KD for xen-devel@lists.xenproject.org; Mon, 23 Sep 2013 17:03:25 +0000 In-Reply-To: <524070E8.8000900@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: Suravee Suthikulpanit Cc: xen-devel , Jan Beulich List-Id: xen-devel@lists.xenproject.org --===============1739170282363379294== Content-Type: multipart/alternative; boundary="------------040301080509040804010905" --------------040301080509040804010905 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 23/09/13 17:48, Suravee Suthikulpanit wrote: > On 9/23/2013 1:52 AM, Jan Beulich wrote: >>>>> On 20.09.13 at 23:38, Suravee Suthikulanit >> wrote: >>> On 9/17/2013 10:30 AM, Jan Beulich wrote: >>>>>> This (unconditional) assignment is what the earlier logic attempted >>>>>>>> to avoid: We must not blindly set this (and in particular not blindly >>>>>>>> overwrite a previously set valid value), and in order to do so we >>>>>>>> need to know whether to trust devid or handle. I'm therefore going >>>>>>>> to apply only the first hunk - being a clear and obvious bug fix - for >>>>>>>> the time being. >>>>>>>> >>>>>> But since we only allow one HPET in the system, and if users want to >>>>>> override the one that is in the IVRS (the buggy one) >>>>>> we should allow this, right? Otherwise, if the special->handle doesn't >>>>>> match, it would end up causing this logic to complain >>>>>> about multiple HPETs. >>>> We must not allow multiple HPET entries in the ACPI tables to >>>> confuse us and store a bad IOMMU pointer. >>> I understand this part and agree. Currently, the patch does not allow >>> multiple HPET in the system. >>> If user specifies the ivrs_hpet, that will be the one that get used, and >>> ignore the one that >>> is in the IVRS. Although, it will be pointing to the IOMMU which lists >>> HPET in the IVRS. >>> >>> However, if IVRS is listing multiple HPETs in different IOMMUs, then it >>> will just default to the first IOMMU. >>> I don't see this case happening though since HPET is in the Southbridge >>> which only has one in the system. >>> >>> Am I missing any thing? >> Yes - there's no guarantee that (especially in a multi-node >> system) there's just one HPET. Nor do the ACPI tables have >> any indication there this would always be the case. Even if >> _all_ current systems only have a single HPET (which I don't >> think you can guarantee), we shouldn't code in a latent bug >> like this. >> >> Jan > I am a bit confused on what you want to do. I believe all the systems > at this point > should have only one HPET. That's why the code only has one data > structure for > initialize one HPET. Are you expecting that certain systems could > have more than > one HPETs? Amongst the test servers we have, I have plenty of examples of AMD hardware with anything up to 8 HPETs in the system. (See for reference my HPET stack overflow thread) ~Andrew --------------040301080509040804010905 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 23/09/13 17:48, Suravee Suthikulpanit wrote:
On 9/23/2013 1:52 AM, Jan Beulich wrote:
On 20.09.13 at 23:38, Suravee Suthikulanit <suravee.suthikulpanit@amd.com>

wrote:

On 9/17/2013 10:30 AM, Jan Beulich wrote:

This (unconditional) assignment is what the earlier logic attempted

to avoid: We must not blindly set this (and in particular not blindly
overwrite a previously set valid value), and in order to do so we
need to know whether to trust devid or handle. I'm therefore going
to apply only the first hunk - being a clear and obvious bug fix - for
the time being.


But since we only allow one HPET in the system, and if users want to
override the one that is in the IVRS (the buggy one)
we should allow this, right?  Otherwise, if the special->handle doesn't
match, it would end up causing this logic to complain
about multiple HPETs.

We must not allow multiple HPET entries in the ACPI tables to
confuse us and store a bad IOMMU pointer.

I understand this part and agree.  Currently, the patch does not allow 
multiple HPET in the system.
If user specifies the ivrs_hpet, that will be the one that get used, and 
ignore the one that
is in the IVRS.  Although, it will be pointing to the IOMMU which lists 
HPET in the IVRS.

However, if IVRS is listing multiple HPETs in different IOMMUs, then it 
will just default to the first IOMMU.
I don't see this case happening though since HPET is in the Southbridge 
which only has one in the system.

Am I missing any thing?

Yes - there's no guarantee that (especially in a multi-node
system) there's just one HPET. Nor do the ACPI tables have
any indication there this would always be the case. Even if
_all_ current systems only have a single HPET (which I don't
think you can guarantee), we shouldn't code in a latent bug
like this.

Jan
I am a bit confused on what you want to do.  I believe all the systems at this point
should have only one HPET.  That's why the code only has one data structure for
initialize one HPET.  Are you expecting that certain systems could have more than
one HPETs?

Amongst the test servers we have, I have plenty of examples of AMD hardware with anything up to 8 HPETs in the system.  (See for reference my HPET stack overflow thread)

~Andrew
--------------040301080509040804010905-- --===============1739170282363379294== 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 --===============1739170282363379294==--