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

Re: [PATCH v7 3/8] AMD/IOMMU: improve (extended) feature detection


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 26 Aug 2021 15:13:40 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GmqyGVlPHw9V6n5aWvNi1Fn0qM38HP/qokgUjALM4gA=; b=VBhSdpIUzHS2718goqcVRkVrm1nJxj9JkI1/L+Ht7xcWvkNtkkJNLuoLoLByspw6HdUIKNYj2mU/24CalcukySTRIhwR736l67tguvfczn8g9U3jQJWmS8pm6XFnJ9Eex+/845RRX2IH0iSOmS8blGxgRg3im/FCoE2z07dokR+EMrjCfOz3cdHredkxiLYbSTpGMHtKHHGjsUxT76LAEpFjCSg2Ua5VQyFogufvsnjVfCXcmBGYQ0Nw0zpjrxvg3xX1Hf1qz2rMG+8fGGFRX8GXvkTrEMbNFUVL7p0u28MziWfqNwPO++wy42lUqy7IEkX0sZh3dwOxk7qb+qSPJA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MLKRK0ZL8GOoofkbmYKhzut7P8TtytazJuyVDCTYhmroVKCRkPlGnBoyGcM0l7XmtZPoYqqwC3v7teswKz7k48Z0wbR8i34w8DcmRM8FlK62x5h65spMg9Qa+hLQv+X+qMF61A16QUiBBvXteS8BZobYkYjKnbwj/tFpZV6IcLwYyuOdd4vy5tpX6AG970Gk0AFcUAe2IsNmBvvWEtiTfxl4asJ7hVUFjbjVZZ5/bDr742WQnRSwofeZ+5x6QTNZTGHbjSWlkiOHePeYPEbJFb74LbRzjSzOxAXfk4vbztuXL0uDZ197+ZnoPy9bwYk/sYLsj9H0Md/pkav5B7Vz5A==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: Paul Durrant <paul@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 26 Aug 2021 13:13:54 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 26.08.2021 15:02, Andrew Cooper wrote:
> On 26/08/2021 08:23, Jan Beulich wrote:
>> First of all the documentation is very clear about ACPI table data
>> superseding raw register data. Use raw register data only if EFRSup is
>> clear in the ACPI tables (which may still go too far). Additionally if
>> this flag is clear, the IVRS type 11H table is reserved and hence may
>> not be recognized.
> 
> The spec says:
> 
> Software Implementation Note: Information conveyed in the IVRS overrides
> the corresponding
> information available through the IOMMU hardware registers. System
> software is required to honor
> the ACPI settings.
> 
> This suggests that if there is an ACPI table, the hardware registers
> shouldn't be followed.
> 
> Given what else is broken when there is no APCI table, I think we can
> (and should) not support this configuration.

Well, we don't. We do require ACPI tables. But that's not the question
here. Instead what this is about is whether the ACPI table has EFRSup
clear. This flag being clear when the register actually exists is imo
more likely a firmware bug.

Plus I didn't want to go too far in one step; I do acknowledge that
we may want to be even more strict down the road by saying "(which may
still go too far)".

>> Furthermore propagate IVRS type 10H data into the feature flags
>> recorded, as the full extended features field is available in type 11H
>> only.
>>
>> Note that this also makes necessary to stop the bad practice of us
>> finding a type 11H IVHD entry, but still processing the type 10H one
>> in detect_iommu_acpi()'s invocation of amd_iommu_detect_one_acpi().
> 
> I could have sworn I read in the spec that if 11H is present, 10H should
> be ignored, but I can't actually locate a statement to this effect.

What I can find is "It is recommended for system software to detect
IOMMU features from the fields in the IVHD Type11h structure
information, superseding information in Type10h block and MMIO
registers."

Jan




 


Rackspace

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