All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Lu Baolu <baolu.lu@linux.intel.com>,
	Kevin Tian <kevin.tian@intel.com>, Joerg Roedel <joro@8bytes.org>,
	Will Deacon <will@kernel.org>,
	Alex Williamson <alex.williamson@redhat.com>,
	Nicolin Chen <nicolinc@nvidia.com>,
	iommu@lists.linux.dev, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] iommu: Prevent RESV_DIRECT devices from blocking domains
Date: Mon, 19 Jun 2023 10:41:56 -0300	[thread overview]
Message-ID: <ZJBbJHevOa8mAdll@nvidia.com> (raw)
In-Reply-To: <5d0d6665-93e4-f61f-d700-008c0fcb4a2f@arm.com>

On Mon, Jun 19, 2023 at 02:33:18PM +0100, Robin Murphy wrote:
> > @@ -2121,6 +2125,21 @@ static int __iommu_device_set_domain(struct iommu_group *group,
> >   {
> >   	int ret;
> > +	/*
> > +	 * If the driver has requested IOMMU_RESV_DIRECT then we cannot allow
> > +	 * the blocking domain to be attached as it does not contain the
> > +	 * required 1:1 mapping. This test effectively exclusive the device from
> > +	 * being used with iommu_group_claim_dma_owner() which will block vfio
> > +	 * and iommufd as well.
> > +	 */
> > +	if (dev->iommu->requires_direct &&
> > +	    (new_domain->type == IOMMU_DOMAIN_BLOCKED ||
> 
> Given the notion elsewhere that we want to use the blocking domain as a last
> resort to handle an attach failure,

We shouldn't do that for cases where requires_direct is true, the last
resort will have to be the static identity domain.

> at face value it looks suspect that failing to attach to a blocking
> domain could also be a thing. I guess technically this is failing at
> a slightly different level so maybe it does work out OK, but it's
> still smelly.

It basically says that this driver doesn't support blocking domains on
this device. What we don't want is for the driver to fail blocking or
identity attaches.
 
> The main thing, though, is that not everything implements the
> IOMMU_DOMAIN_BLOCKED optimisation, so a nominal blocking domain could be
> IOMMU_DOMAIN_UNMANAGED as well. 

Yes, it should check new_domain == group->blocking_domain as well.

> FWIW I'd prefer to make the RESV_DIRECT check explicit in
> __iommu_take_dma_ownership() rather than hide it in an
> implementation detail; that's going to be a lot clearer to reason
> about as time goes on.

We want to completely forbid blocking domains at all on these devices
because they are not supported (by FW request). I don't really like
the idea that we go and assume the only users of blocking domains are
also using take_dma_ownership() - that feels like a future bug waiting
to happen.

Jason

  reply	other threads:[~2023-06-19 13:42 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-07  3:51 [PATCH 0/2] Prevent RESV_DIRECT devices from user assignment Lu Baolu
2023-06-07  3:51 ` [PATCH 1/2] iommu: Prevent RESV_DIRECT devices from blocking domains Lu Baolu
2023-06-12  8:28   ` Liu, Jingqi
2023-06-13  3:14     ` Baolu Lu
2023-06-27  7:54       ` Tian, Kevin
2023-06-27  8:01         ` Baolu Lu
2023-06-27  8:15           ` Tian, Kevin
2023-06-27  8:21             ` Baolu Lu
2023-06-27 15:47           ` Jason Gunthorpe
2023-06-19 13:33   ` Robin Murphy
2023-06-19 13:41     ` Jason Gunthorpe [this message]
2023-06-19 14:20       ` Robin Murphy
2023-06-19 15:30         ` Jason Gunthorpe
2023-06-27  8:10           ` Tian, Kevin
2023-06-27 15:49             ` Jason Gunthorpe
2023-06-07  3:51 ` [PATCH 2/2] iommu/vt-d: Remove rmrr check in domain attaching device path Lu Baolu
2023-06-23 16:49   ` Jason Gunthorpe

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=ZJBbJHevOa8mAdll@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=alex.williamson@redhat.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicolinc@nvidia.com \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.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.