KVM Archive mirror
 help / color / mirror / Atom feed
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: "Liu, Yi L" <yi.l.liu@intel.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"robin.murphy@arm.com" <robin.murphy@arm.com>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>,
	"nicolinc@nvidia.com" <nicolinc@nvidia.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>,
	"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
	"Duan, Zhenzhong" <zhenzhong.duan@intel.com>,
	"Pan, Jacob jun" <jacob.jun.pan@intel.com>
Subject: RE: [PATCH v2 02/12] iommu: Introduce a replace API for device pasid
Date: Thu, 18 Apr 2024 00:08:01 +0000	[thread overview]
Message-ID: <BN9PR11MB52760DDE80B5C0CC89F6906E8C0E2@BN9PR11MB5276.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20240417121700.GL3637727@nvidia.com>

> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Wednesday, April 17, 2024 8:17 PM
> 
> On Wed, Apr 17, 2024 at 08:44:11AM +0000, Tian, Kevin wrote:
> > > From: Liu, Yi L <yi.l.liu@intel.com>
> > > Sent: Friday, April 12, 2024 4:15 PM
> > >
> > > -		if (device == last_gdev)
> > > +		/*
> > > +		 * Rollback the devices/pasid that have attached to the new
> > > +		 * domain. And it is a driver bug to fail attaching with a
> > > +		 * previously good domain.
> > > +		 */
> > > +		if (device == last_gdev) {
> > > +			WARN_ON(old->ops->set_dev_pasid(old, device-
> > > >dev,
> > > +							pasid, NULL));
> >
> > do we have a clear definition that @set_dev_pasid callback should
> > leave the device detached (as 'NULL' indicates) or we just don't
> > care the currently-attached domain at this point?
> 
> If set_dev_pasid fails I would expect to to have done nothing so the
> failing device should be left in the old config and we should just not
> call it at all.
> 
> The RID path is wonky here because so many drivers don't do that, so
> we poke them again to hopefully get it right. I think for PASID we
> should try to make the drivers work properly from the start. Failure
> means no change.
> 
> I would summarize this in a comment..

Ah yes, that's the simple sane way to do. 😊

  reply	other threads:[~2024-04-18  0:08 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-12  8:15 [PATCH v2 00/12] iommufd support pasid attach/replace Yi Liu
2024-04-12  8:15 ` [PATCH v2 01/12] iommu: Pass old domain to set_dev_pasid op Yi Liu
2024-04-15  5:32   ` Baolu Lu
2024-04-15 11:54     ` Jason Gunthorpe
2024-04-16  2:07       ` Baolu Lu
2024-04-16 17:47         ` Jason Gunthorpe
2024-04-12  8:15 ` [PATCH v2 02/12] iommu: Introduce a replace API for device pasid Yi Liu
2024-04-16  3:01   ` Duan, Zhenzhong
2024-04-16  9:18     ` Yi Liu
2024-04-17  8:44   ` Tian, Kevin
2024-04-17 12:17     ` Jason Gunthorpe
2024-04-18  0:08       ` Tian, Kevin [this message]
2024-04-29 13:55   ` Jason Gunthorpe
2024-04-30  5:00     ` Yi Liu
2024-04-30 12:26       ` Jason Gunthorpe
2024-04-12  8:15 ` [PATCH v2 03/12] iommufd: replace attach_fn with a structure Yi Liu
2024-04-12  8:15 ` [PATCH v2 04/12] iommufd: Support attach/replace hwpt per pasid Yi Liu
2024-04-29 13:56   ` Jason Gunthorpe
2024-04-12  8:15 ` [PATCH v2 05/12] iommu: Allow iommu driver to populate the max_pasids Yi Liu
2024-04-15  5:41   ` Baolu Lu
2024-04-17  8:49     ` Tian, Kevin
2024-04-20  5:45       ` Yi Liu
2024-04-22 11:52         ` Jason Gunthorpe
2024-04-12  8:15 ` [PATCH v2 06/12] iommufd/selftest: Add set_dev_pasid and remove_dev_pasid in mock iommu Yi Liu
2024-04-12  8:15 ` [PATCH v2 07/12] iommufd/selftest: Add a helper to get test device Yi Liu
2024-04-12  8:15 ` [PATCH v2 08/12] iommufd/selftest: Add test ops to test pasid attach/detach Yi Liu
2024-04-12  8:15 ` [PATCH v2 09/12] iommufd/selftest: Add coverage for iommufd " Yi Liu
2024-04-12  8:15 ` [PATCH v2 10/12] iommu/vt-d: Return if no dev_pasid is found in domain Yi Liu
2024-04-15  6:04   ` Baolu Lu
2024-04-16  9:21     ` Yi Liu
2024-04-17  2:30       ` Baolu Lu
2024-04-17  3:48         ` Yi Liu
2024-04-17  9:03   ` Tian, Kevin
2024-04-17  9:36     ` Yi Liu
2024-04-12  8:15 ` [PATCH v2 11/12] iommu/vt-d: Make intel_iommu_set_dev_pasid() to handle domain replacement Yi Liu
2024-04-17  9:19   ` Tian, Kevin
2024-04-17  9:35     ` Yi Liu
2024-04-17 12:19       ` Jason Gunthorpe
2024-04-12  8:15 ` [PATCH v2 12/12] iommu/vt-d: Add set_dev_pasid callback for nested domain Yi Liu
2024-04-17  9:25   ` Tian, Kevin
2024-04-30  9:19     ` Yi Liu
2024-05-06  7:42       ` Baolu Lu
2024-05-06 13:36         ` Jason Gunthorpe
2024-05-07  2:28           ` Yi Liu
2024-05-07 15:18             ` Jason Gunthorpe
2024-05-08  6:10               ` Yi Liu
2024-05-08 12:25                 ` Jason Gunthorpe
2024-05-08 13:26                   ` Yi Liu
2024-05-08 14:11                     ` Jason Gunthorpe
2024-05-09 14:22                       ` Liu, Yi L

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=BN9PR11MB52760DDE80B5C0CC89F6906E8C0E2@BN9PR11MB5276.namprd11.prod.outlook.com \
    --to=kevin.tian@intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=chao.p.peng@linux.intel.com \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux.dev \
    --cc=jacob.jun.pan@intel.com \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=nicolinc@nvidia.com \
    --cc=robin.murphy@arm.com \
    --cc=yi.l.liu@intel.com \
    --cc=zhenzhong.duan@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 read-only IMAP folder(s) and NNTP newsgroup(s).