All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Paul Durrant <paul@xen.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v7 3/8] AMD/IOMMU: improve (extended) feature detection
Date: Thu, 26 Aug 2021 15:13:40 +0200	[thread overview]
Message-ID: <ed2ee574-b36a-dd3a-ee9f-4b2385a0a2e9@suse.com> (raw)
In-Reply-To: <1449dfd9-7617-b4cc-89b1-3e9dd8090320@citrix.com>

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



  reply	other threads:[~2021-08-26 13:14 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-26  7:21 [PATCH v7] AMD/IOMMU: further work split from XSA-378 Jan Beulich
2021-08-26  7:23 ` [PATCH v7 1/8] AMD/IOMMU: check / convert IVMD ranges for being / to be reserved Jan Beulich
2021-08-26 12:10   ` Andrew Cooper
2021-08-26 12:31     ` Jan Beulich
2021-09-21  7:37       ` Jan Beulich
2021-08-26  7:23 ` [PATCH v7 2/8] AMD/IOMMU: obtain IVHD type to use earlier Jan Beulich
2021-08-26 12:30   ` Andrew Cooper
2021-08-26 12:33     ` Jan Beulich
2021-08-26  7:23 ` [PATCH v7 3/8] AMD/IOMMU: improve (extended) feature detection Jan Beulich
2021-08-26 13:02   ` Andrew Cooper
2021-08-26 13:13     ` Jan Beulich [this message]
2021-08-26  7:24 ` [PATCH v7 4/8] AMD/IOMMU: check IVMD ranges against host implementation limits Jan Beulich
2021-08-26 13:16   ` Andrew Cooper
2021-08-26 14:03     ` Jan Beulich
2021-08-26  7:24 ` [PATCH v7 5/8] AMD/IOMMU: also insert IVMD ranges into Dom0's page tables Jan Beulich
2021-08-26  7:25 ` [PATCH v7 6/8] AMD/IOMMU: provide function backing XENMEM_reserved_device_memory_map Jan Beulich
2021-08-26 13:24   ` Andrew Cooper
2021-08-26 14:05     ` Jan Beulich
2021-08-26  7:25 ` [PATCH v7 7/8] AMD/IOMMU: add "ivmd=" command line option Jan Beulich
2021-08-26 14:08   ` Andrew Cooper
2021-08-26 14:30     ` Jan Beulich
2021-08-26  7:26 ` [PATCH v7 8/8] AMD/IOMMU: respect AtsDisabled device flag Jan Beulich
2021-08-26 14:27   ` Andrew Cooper
2021-08-26 14:33     ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ed2ee574-b36a-dd3a-ee9f-4b2385a0a2e9@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=paul@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.