From: Jason Gunthorpe <jgg@nvidia.com>
To: "Tian, Kevin" <kevin.tian@intel.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>
Subject: Re: [PATCH 0/6] Make set_dev_pasid op supportting domain replacement
Date: Mon, 15 Jul 2024 09:19:08 -0300 [thread overview]
Message-ID: <20240715121908.GS1482543@nvidia.com> (raw)
In-Reply-To: <BN9PR11MB52760966CBFA7DB116ADCA338CA12@BN9PR11MB5276.namprd11.prod.outlook.com>
On Mon, Jul 15, 2024 at 08:16:40AM +0000, Tian, Kevin wrote:
> > Then the description is sort of like
> >
> > Replace is useful for iommufd/VFIO to provide perfect HW emulation in
> > case the VM is expecting to be able to change a PASID on the fly. As
> > AMD will only support PASID in VM's using nested translation where we
> > don't use the set_dev_pasid API leave it disabled for now.
> >
>
> yes that's clearer.
>
> btw I don't remember whether we have discussed the rationale behind
> the different driver semantics between RID and PASID. Currently RID
> replace is same as RID attach, with the driver simply blocking the old
> translation from the start and then no rollback upon failure when
> switching to the new domain (expecting the iommu core to recover),
> while for PASID replace we expect the driver to implement the hitless
> switch.
>
> Is it because there is no need of perfect HW emulation for RID or just
> to be cleaned up later?
Yeah, too much legacy it would be hard to go in and do something about
this for RID across every driver.
PASID can be a bit more well defined from the start since we only have
three drivers and two of them support replace.
An ideal driver should be like ARM and support hitless replace
whenever possible in all paths so there is no confusion within the
driver.
Jason
next prev parent reply other threads:[~2024-07-15 12:19 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-28 8:55 [PATCH 0/6] Make set_dev_pasid op supportting domain replacement Yi Liu
2024-06-28 8:55 ` [PATCH 1/6] iommu: Pass old domain to set_dev_pasid op Yi Liu
2024-06-28 8:55 ` [PATCH 2/6] iommu/vt-d: Move intel_drain_pasid_prq() into intel_pasid_tear_down_entry() Yi Liu
2024-06-28 9:42 ` Baolu Lu
2024-06-28 10:51 ` Yi Liu
2024-07-10 8:25 ` Tian, Kevin
2024-06-28 8:55 ` [PATCH 3/6] iommu/vt-d: Make helpers support modifying present pasid entry Yi Liu
2024-06-28 9:52 ` Baolu Lu
2024-06-28 10:56 ` Yi Liu
2024-07-15 7:53 ` Tian, Kevin
2024-07-15 8:05 ` Yi Liu
2024-06-28 8:55 ` [PATCH 4/6] iommu/vt-d: Make intel_iommu_set_dev_pasid() to handle domain replacement Yi Liu
2024-07-15 7:58 ` Tian, Kevin
2024-06-28 8:55 ` [PATCH 5/6] iommu/vt-d: Add set_dev_pasid callback for nested domain Yi Liu
2024-06-28 8:55 ` [PATCH 6/6] iommu: Make set_dev_pasid op support domain replacement Yi Liu
2024-07-15 8:02 ` Tian, Kevin
2024-07-15 8:37 ` Yi Liu
2024-07-10 8:24 ` [PATCH 0/6] Make set_dev_pasid op supportting " Tian, Kevin
2024-07-11 18:41 ` Jason Gunthorpe
2024-07-15 8:16 ` Tian, Kevin
2024-07-15 12:19 ` Jason Gunthorpe [this message]
2024-07-15 8:23 ` Yi Liu
2024-07-15 12:19 ` Jason Gunthorpe
2024-07-16 2:07 ` Yi Liu
2024-07-11 18:37 ` Jason Gunthorpe
2024-07-15 8:11 ` Yi Liu
2024-07-15 12:16 ` Jason Gunthorpe
2024-08-15 17:49 ` Vasant Hegde
2024-08-16 1:19 ` Yi Liu
2024-08-16 2:49 ` Baolu Lu
2024-08-16 5:17 ` Vasant Hegde
2024-08-16 2:52 ` Baolu Lu
2024-08-16 6:08 ` Yi Liu
2024-08-16 5:19 ` Vasant Hegde
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=20240715121908.GS1482543@nvidia.com \
--to=jgg@nvidia.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=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=robin.murphy@arm.com \
--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