All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Kevin Tian <kevin.tian@intel.com>, Paul Durrant <paul@xen.org>
Subject: Re: [PATCH v2 06/12] VT-d: respect ACPI SATC's ATC_REQUIRED flag
Date: Mon, 20 May 2024 13:36:08 +0200	[thread overview]
Message-ID: <Zks1qFNsQdLkOCAs@macbook> (raw)
In-Reply-To: <e9281523-a807-4889-80f0-a13804188af9@suse.com>

On Wed, May 15, 2024 at 12:42:40PM +0200, Jan Beulich wrote:
> On 06.05.2024 15:38, Roger Pau Monné wrote:
> > On Thu, Feb 15, 2024 at 11:16:11AM +0100, Jan Beulich wrote:
> >> When the flag is set, permit Dom0 to control the device (no worse than
> >> what we had before and in line with other "best effort" behavior we use
> >> when it comes to Dom0),
> > 
> > I think we should somehow be able to signal dom0 that this device
> > might not operate as expected, otherwise dom0 might use it and the
> > device could silently malfunction due to ATS not being enabled.
> 
> Whatever signaling we invented, no Dom0 would be required to respect it,
> and for (perhaps quite) some time no Dom0 kernel would even exist to query
> that property.
> 
> > Otherwise we should just hide the device from dom0.
> 
> This would feel wrong to me, almost like a regression from what we had
> before.

Exposing a device to dom0 that won't be functional doesn't seem like a
very wise choice from Xen TBH.

> > I assume setting the IOMMU context entry to passthrough mode would
> > also be fine for such devices that require ATS?
> 
> I'm afraid I'm lacking the connection of the question to what is being
> done here. Can you perhaps provide some more context? To provide some
> context from my side: Using pass-through mode would be excluded when Dom0
> is PVH. Hence why I'm not getting why we would want to even just consider
> doing so.
> 
> Yet, looking at the spec, in pass-through mode translation requests are
> treated as UR. So maybe your question was towards there needing to be
> handling (whichever way) for the case where pass-through mode was
> requested for PV Dom0? The only half-way sensible thing to do in that case
> that I can think of right now would be to ignore that command line option,

Hm, maybe I'm confused, but if the IOMMU device context entry is set
in pass-through mode ATS won't be enabled and hence no translation
requests would be send from the device?

IOW, devices listed in the SATC can only mandate ATS enabled when the
IOMMU is enforcing translation.   IF the IOMMU is not enabled or if
the device is in passthrough mode then the requirement for having ATS
enabled no longer applies.

Thanks, Roger.


  reply	other threads:[~2024-05-20 11:36 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-15 10:11 [PATCH v2 00/12] VT-d: SATC handling; ATS: tidying Jan Beulich
2024-02-15 10:13 ` [PATCH v2 01/12] VT-d: correct ATS checking for root complex integrated devices Jan Beulich
2024-05-03 14:01   ` Roger Pau Monné
2024-02-15 10:14 ` [PATCH v2 02/12] VT-d: tidy error handling of RMRR parsing Jan Beulich
2024-05-06  9:12   ` Roger Pau Monné
2024-05-06  9:21     ` Jan Beulich
2024-05-06  9:26       ` Roger Pau Monné
2024-02-15 10:14 ` [PATCH v2 03/12] VT-d: parse ACPI "SoC Integrated Address Translation Cache Reporting Structure"s Jan Beulich
2024-05-06 10:29   ` Roger Pau Monné
2024-05-06 11:01     ` Jan Beulich
2024-05-06 11:09       ` Roger Pau Monné
2024-02-15 10:15 ` [PATCH v2 04/12] AMD/IOMMU: add helper to check whether ATS is to be used for a device Jan Beulich
2024-05-06 11:27   ` Roger Pau Monné
2024-02-15 10:15 ` [PATCH v2 05/12] IOMMU: rename and re-type ats_enabled Jan Beulich
2024-02-15 10:21   ` Jan Beulich
2024-05-06 12:42   ` Roger Pau Monné
2024-05-06 13:20     ` Jan Beulich
2024-05-06 13:53       ` Roger Pau Monné
2024-05-15 10:07         ` Jan Beulich
2024-05-20 10:29           ` Roger Pau Monné
2024-05-21  6:21             ` Jan Beulich
2024-05-21 10:03               ` Roger Pau Monné
2024-05-21 10:23                 ` Jan Beulich
2024-02-15 10:16 ` [PATCH v2 06/12] VT-d: respect ACPI SATC's ATC_REQUIRED flag Jan Beulich
2024-05-06 13:38   ` Roger Pau Monné
2024-05-15 10:42     ` Jan Beulich
2024-05-20 11:36       ` Roger Pau Monné [this message]
2024-05-21  6:25         ` Jan Beulich
2025-10-23 13:30   ` Teddy Astie
2025-10-27 11:23     ` Jan Beulich
2024-02-15 10:16 ` [PATCH v2 07/12] VT-d: replace find_ats_dev_drhd() Jan Beulich
2024-02-15 10:17 ` [PATCH v2 08/12] VT-d: move ats_device() to the sole file it's used from Jan Beulich
2024-02-15 10:18 ` [PATCH v2 09/12] VT-d: move dev_invalidate_iotlb() " Jan Beulich
2024-02-15 10:18 ` [PATCH v2 10/12] VT-d: move {,un}map_vtd_domain_page() Jan Beulich
2024-02-15 10:18 ` [PATCH v2 11/12] VT-d: drop flush_dev_iotlb parameter from IOTLB flush hook Jan Beulich
2024-05-06 14:06   ` Roger Pau Monné
2024-02-15 10:19 ` [PATCH v2 12/12] PCI/ATS: tidy {en,dis}able_ats_device() a little Jan Beulich
2024-05-06 14:10   ` Roger Pau Monné

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=Zks1qFNsQdLkOCAs@macbook \
    --to=roger.pau@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=kevin.tian@intel.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.