All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Kevin Tian <kevin.tian@intel.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH] VT-d: Tylersburg errata apply to further steppings
Date: Tue, 3 Aug 2021 15:52:20 +0200	[thread overview]
Message-ID: <YQlKFVOFOjevmIXO@mail-itl> (raw)
In-Reply-To: <f9f613a6-cf27-8432-c877-95a8516216c6@suse.com>

[-- Attachment #1: Type: text/plain, Size: 2637 bytes --]

On Tue, Aug 03, 2021 at 03:44:10PM +0200, Jan Beulich wrote:
> On 03.08.2021 15:30, Marek Marczykowski-Górecki wrote:
> > On Tue, Aug 03, 2021 at 03:16:14PM +0200, Jan Beulich wrote:
> >> On 03.08.2021 15:12, Marek Marczykowski-Górecki wrote:
> >>> On Tue, Aug 03, 2021 at 03:06:50PM +0200, Jan Beulich wrote:
> >>>> On 03.08.2021 15:01, Marek Marczykowski-Górecki wrote:
> >>>>> Ok, then, just setting iommu_intremap=false should do the right thing,
> >>>>
> >>>> ... if "iommu=force" is in use (but not otherwise), ...
> >>>
> >>> But that's the purpose of iommu=force, no?
> >>> With "iommu=force": strictly require IOMMU
> >>> Without "iommu=force": use IOMMU on best-effort basis
> >>>
> >>> It makes sense to refuse the boot if intremap is broken in the first
> >>> case. But also, it makes sense to allow using IOMMU without intremp in
> >>> the second case.
> >>
> >> I agree with both statements. What I disagree with is that the latter
> >> happens by default (instead of only upon admin override), including
> >> the case of intremap being unavailable in the first place.
> > 
> > "upon admin override" - do I read the code right, that iommu=no-intremap
> > will actually achieve this effect?
> 
> In the case of this quirk - yes, as the call to the checking function is
> gated by a check of iommu_intremap. But by "admin override" I meant a
> per-guest attribute, not a host-wide one that isn't explicitly meant to
> cover all guests.
> 
> > Will that allow to use IOMMU without
> > interrupt remapping on a hardware where it's broken? In that case, maybe
> > at least add this info to the log message?
> 
> You mean to suggest the use of this option? I'd rather not, to be honest.
> I don't think options like this should be suggested to be used. I'd
> prefer if we had less of such options, i.e. if they went away after some
> initial integration phase.

Indeed, in fact I agree, this should be per-guest configurable option
(and in some cases, it kind of is - toolstack will refuse to boot a 
domain with PCI devices if IOMMU is missing). But, as you noted earlier,
there is no way to require intremap, on per-domain basis (regardless of
what the default behavior would be).

As for optionally requiring IOMMU host-wide, this still makes sense, as
IOMMU could be used not only for PCI passthrough, but also to protect
dom0 from some (possibly hot-plugged) devices - using quarantine
feature. There may be also some desired interactions with Intel TXT
(which AFAIR itself requires working VT-d).

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2021-08-03 13:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-03 11:13 [PATCH] VT-d: Tylersburg errata apply to further steppings Jan Beulich
2021-08-03 12:21 ` Marek Marczykowski-Górecki
2021-08-03 12:29   ` Jan Beulich
2021-08-03 13:01     ` Marek Marczykowski-Górecki
2021-08-03 13:06       ` Jan Beulich
2021-08-03 13:12         ` Marek Marczykowski-Górecki
2021-08-03 13:16           ` Jan Beulich
2021-08-03 13:30             ` Marek Marczykowski-Górecki
2021-08-03 13:44               ` Jan Beulich
2021-08-03 13:52                 ` Marek Marczykowski-Górecki [this message]
2021-08-17  3:02 ` Tian, Kevin
2021-08-18 11:32 ` Andrew Cooper
2021-08-18 12:02   ` 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=YQlKFVOFOjevmIXO@mail-itl \
    --to=marmarek@invisiblethingslab.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=kevin.tian@intel.com \
    --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.