All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
	Paul Durrant <paul@xen.org>
Subject: Re: [PATCH v2 3/3] AMD/IOMMU: iommu_enable vs iommu_intremap
Date: Tue, 2 Nov 2021 11:13:08 +0100	[thread overview]
Message-ID: <dd2929fc-dc1a-1c16-5954-6894766d9dda@suse.com> (raw)
In-Reply-To: <YXaGxX3J1aB39mSG@MacBook-Air-de-Roger.local>

On 25.10.2021 12:28, Roger Pau Monné wrote:
> On Thu, Oct 21, 2021 at 11:59:02AM +0200, Jan Beulich wrote:
>> The two are really meant to be independent settings; iov_supports_xt()
>> using || instead of && was simply wrong. The corrected check is,
>> however, redundant, just like the (correct) one in iov_detect(): These
>> hook functions are unreachable without acpi_ivrs_init() installing the
>> iommu_init_ops pointer, which it does only upon success. (Unlike for
>> VT-d there is no late clearing of iommu_enable due to quirks, and any
>> possible clearing of iommu_intremap happens only after iov_supports_xt()
>> has run.)
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> In fact in iov_detect() it could be iommu_enable alone which gets
>> checked, but this felt overly aggressive to me. Instead I'm getting the
>> impression that the function may wrongly not get called when "iommu=off"
>> but interrupt remapping is in use: We'd not get the interrupt handler
>> installed, and hence interrupt remapping related events would never get
>> reported. (Same on VT-d, FTAOD.)
> 
> I've spend a non-trivial amount of time looking into this before
> reading this note. AFAICT you could set iommu=off and still get x2APIC
> enabled and relying on interrupt remapping.

Right, contrary to ...

>> For iov_supports_xt() the question is whether, like VT-d's
>> intel_iommu_supports_eim(), it shouldn't rather check iommu_intremap
>> alone (in which case it would need to remain a check rather than getting
>> converted to ASSERT()).
> 
> Hm, no, I don't think so. I think iommu_enable should take precedence
> over iommu_intremap, and having iommu_enable == false should force
> interrupt remapping to be reported as disabled. Note that disabling it
> in iommu_setup is too late, as the APIC initialization will have
> already taken place.
> 
> It's my reading of the command line parameter documentation that
> setting iommu=off should disable all usage of the IOMMU, and that
> includes the interrupt remapping support (ie: a user should not need
> to set iommu=off,no-intremap)

... that documentation. But I think it's the documentation that
wants fixing, such that iommu=off really only control DMA remap.
With that ...

>> ---
>> v2: New.
>>
>> --- a/xen/drivers/passthrough/amd/iommu_intr.c
>> +++ b/xen/drivers/passthrough/amd/iommu_intr.c
>> @@ -731,8 +731,7 @@ bool __init iov_supports_xt(void)
>>  {
>>      unsigned int apic;
>>  
>> -    if ( !iommu_enable || !iommu_intremap )
>> -        return false;
>> +    ASSERT(iommu_enable || iommu_intremap);
> 
> I think this should be && in order to match my comments above.

... I think || is correct to use here.

Jan



  reply	other threads:[~2021-11-02 10:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-21  9:57 [PATCH v2 0/3] x86/IOMMU: enabled / intremap handling Jan Beulich
2021-10-21  9:58 ` [PATCH v2 1/3] x86/IOMMU: mark IOMMU / intremap not in use when ACPI tables are missing Jan Beulich
2021-10-22  5:59   ` Jan Beulich
2021-10-29  8:44     ` Tian, Kevin
2021-10-22 15:52   ` Roger Pau Monné
2021-11-02 10:07     ` Jan Beulich
2021-11-02 10:26       ` Roger Pau Monné
2021-10-21  9:58 ` [PATCH v2 2/3] x86/APIC: avoid iommu_supports_x2apic() on error path Jan Beulich
2021-10-25  8:41   ` Roger Pau Monné
2021-10-21  9:59 ` [PATCH v2 3/3] AMD/IOMMU: iommu_enable vs iommu_intremap Jan Beulich
2021-10-25 10:28   ` Roger Pau Monné
2021-11-02 10:13     ` Jan Beulich [this message]
2021-11-02 11:03       ` Roger Pau Monné
2021-11-02 14:00         ` Jan Beulich
2021-11-02 14:59           ` Roger Pau Monné
2021-11-03  9:46         ` Jan Beulich
2021-11-03 15:06           ` Roger Pau Monné
2021-11-03 15:15             ` Jan Beulich
2021-11-03 17:00               ` Roger Pau Monné
2021-11-02 10:17 ` [PATCH v2 0/3] x86/IOMMU: enabled / intremap handling Jan Beulich
2021-11-03 11:01   ` [PATCH v2 0/3][4.16] " Jan Beulich
2021-11-03 16:19     ` Ian Jackson
2021-11-04  8:15       ` Jan Beulich
2021-11-04 11:10         ` Ian Jackson

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=dd2929fc-dc1a-1c16-5954-6894766d9dda@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=paul@xen.org \
    --cc=roger.pau@citrix.com \
    --cc=wl@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.