Linux IOMMU Development
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>
Cc: joro@8bytes.org, will@kernel.org, robin.murphy@arm.com,
	eric.auger@redhat.com, virtualization@lists.linux-foundation.org,
	iommu@lists.linux.dev, akihiko.odaki@daynix.com
Subject: Re: [PATCH] iommu/virtio: Detach domain on endpoint release
Date: Thu, 18 May 2023 15:17:22 -0300	[thread overview]
Message-ID: <ZGZrsgNX1ALNP2w3@nvidia.com> (raw)
In-Reply-To: <20230518164937.GA2934820@myrica>

On Thu, May 18, 2023 at 05:49:37PM +0100, Jean-Philippe Brucker wrote:
> On Thu, May 18, 2023 at 10:59:12AM -0300, Jason Gunthorpe wrote:
> > On Thu, May 18, 2023 at 02:56:38PM +0100, Jean-Philippe Brucker wrote:
> > > > Can you wrapper this into a BLOCKED domain like we are moving drivers
> > > > toward, and then attach the blocked domain instead of introducing this
> > > > special case?
> > > 
> > > Yes, I think the way the virtio-iommu driver should implement BLOCKED
> > > domains is initially clearing the global-bypass bit, and then issuing
> > > DETACH requests when the core asks to attach a BLOCKED domain. This has
> > > the same effect as issuing an ATTACH request with an empty domain, but
> > > requires fewer resources in the VMM.
> > 
> > Does that exclude identity though?
> 
> No, identity attaches a domain with the ATTACH_F_BYPASS flag (or an
> identity-mapped domain if the feature is missing), it doesn't rely on
> global-bypass.

Oh, so you can clear the global-bypass bit and that turns detach into
blocked then you can model this detach operation with blocked and
still get identity because that is attach with a flag :) Wow, a bit
indirect but OK

> > this, the desired translation mode should always be made
> > explicit.
> 
> I probably misunderstood your plan for BLOCKED. This particular patch is
> about removing devices from the machine, for example PCIe hot-unplug. So I
> thought you were suggesting the core will at some point attach a BLOCKED
> domain to a device being removed, in order to block translation while the
> device is being removed and while a new one is being plugged in with the
> same RID.

Yes, that would be appropriate

> For that case I think DETACH, rather than ATTACH an empty domain,
> makes more sense. Otherwise with the same reasoning we'd need to
> attach all 4 billion endpoint IDs to an empty domain at boot which
> isn't feasible.

Well, this is what the default is for. You can consider the default as
being implicitly attached to BLOCKED or IDENTIY. If you want to change
the translation then you ask to change the translation to some other
defined thing.

Detach is just a confusing idea because it doesn't really say what the
translation changes into - and there is always an active translation.

On the VMM side we always have a translation assigned in VFIO so it
doesn't really matter how the command is carried over.

This command coding is weird, but it seems like it is fine, and the
driver will be clearer when everything is labeled :)

Jason

  reply	other threads:[~2023-05-18 18:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-14 15:07 [PATCH] iommu/virtio: Detach domain on endpoint release Jean-Philippe Brucker
2023-04-20  1:20 ` Akihiko Odaki
2023-05-10  8:11 ` Jean-Philippe Brucker
2023-05-17 16:20   ` Jason Gunthorpe
2023-05-18 13:56     ` Jean-Philippe Brucker
2023-05-18 13:59       ` Jason Gunthorpe
2023-05-18 16:49         ` Jean-Philippe Brucker
2023-05-18 18:17           ` Jason Gunthorpe [this message]
2023-05-10 15:37 ` Eric Auger
2023-05-10 16:20   ` Jean-Philippe Brucker

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=ZGZrsgNX1ALNP2w3@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=akihiko.odaki@daynix.com \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux.dev \
    --cc=jean-philippe@linaro.org \
    --cc=joro@8bytes.org \
    --cc=robin.murphy@arm.com \
    --cc=virtualization@lists.linux-foundation.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox