From: Jason Gunthorpe <jgg@nvidia.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: kevin.tian@intel.com, alex.williamson@redhat.com,
yi.l.liu@intel.com, joro@8bytes.org, will@kernel.org,
robin.murphy@arm.com, shuah@kernel.org,
linux-kernel@vger.kernel.org, iommu@lists.linux.dev,
kvm@vger.kernel.org, linux-kselftest@vger.kernel.org,
mjrosato@linux.ibm.com, farman@linux.ibm.com
Subject: Re: [PATCH v8 2/4] iommufd: Add iommufd_access_replace() API
Date: Thu, 27 Jul 2023 09:03:01 -0300 [thread overview]
Message-ID: <ZMJc9elDILpHaKP6@nvidia.com> (raw)
In-Reply-To: <ZMHdfycdAdmqB2VB@Asurada-Nvidia>
On Wed, Jul 26, 2023 at 07:59:11PM -0700, Nicolin Chen wrote:
> I just realized that either my v8 or your version calls unmap()
> first at the entire cur_ioas. So, there seems to be no point in
> doing that fallback re-add routine since the cur_ioas isn't the
> same, which I don't feel quite right...
The point is to restore the access back to how it should be on failure
so future use of the accesss still does the right thing.
We already have built into this a certain non-atomicity for mdevs,
they can see a pin failure during replace if they race an access
during this unmap window. This is similar to the real HW iommu's
without atomic replace.
> Perhaps we should pass the ID into iopt_add/remove_access like
> you said above. And then we attach the new_ioas, piror to the
> detach the cur_ioas?
If it is simple this seems like the most robust
Jason
next prev parent reply other threads:[~2023-07-27 12:03 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-24 19:47 [PATCH v8 0/4] cover-letter: Add IO page table replacement support Nicolin Chen
2023-07-24 19:47 ` [PATCH v8 1/4] vfio: Do not allow !ops->dma_unmap in vfio_pin/unpin_pages() Nicolin Chen
2023-07-26 17:33 ` Alex Williamson
2023-07-26 17:38 ` Jason Gunthorpe
2023-07-24 19:47 ` [PATCH v8 2/4] iommufd: Add iommufd_access_replace() API Nicolin Chen
2023-07-26 14:30 ` Jason Gunthorpe
2023-07-26 20:50 ` Nicolin Chen
2023-07-26 23:36 ` Jason Gunthorpe
2023-07-27 2:59 ` Nicolin Chen
2023-07-27 7:30 ` Nicolin Chen
2023-07-27 12:03 ` Jason Gunthorpe [this message]
2023-07-27 19:04 ` Nicolin Chen
2023-07-28 3:45 ` Tian, Kevin
2023-07-28 4:43 ` Nicolin Chen
2023-07-28 6:20 ` Tian, Kevin
2023-07-28 12:28 ` Jason Gunthorpe
2023-07-28 12:27 ` Jason Gunthorpe
2023-07-24 19:47 ` [PATCH v8 3/4] iommufd/selftest: Add IOMMU_TEST_OP_ACCESS_REPLACE_IOAS coverage Nicolin Chen
2023-07-26 17:04 ` Jason Gunthorpe
2023-07-24 19:47 ` [PATCH v8 4/4] vfio: Support IO page table replacement Nicolin Chen
2023-07-26 17:04 ` Jason Gunthorpe
2023-07-26 17:34 ` Alex Williamson
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=ZMJc9elDILpHaKP6@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=farman@linux.ibm.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=linux-kselftest@vger.kernel.org \
--cc=mjrosato@linux.ibm.com \
--cc=nicolinc@nvidia.com \
--cc=robin.murphy@arm.com \
--cc=shuah@kernel.org \
--cc=will@kernel.org \
--cc=yi.l.liu@intel.com \
/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;
as well as URLs for NNTP newsgroup(s).