From: "Tian, Kevin" <kevin.tian@intel.com>
To: Lu Baolu <baolu.lu@linux.intel.com>,
Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: "iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Joerg Roedel <joro@8bytes.org>,
"David Woodhouse" <dwmw2@infradead.org>,
Alex Williamson <alex.williamson@redhat.com>,
Jean-Philippe Brucker <jean-philippe@linaro.com>,
"Liu, Yi L" <yi.l.liu@intel.com>,
"Raj, Ashok" <ashok.raj@intel.com>,
Christoph Hellwig <hch@infradead.org>,
"Jonathan Cameron" <jic23@kernel.org>,
Eric Auger <eric.auger@redhat.com>
Subject: RE: [PATCH v7 03/11] iommu/vt-d: Add custom allocator for IOASID
Date: Fri, 25 Oct 2019 15:52:39 +0000 [thread overview]
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D19D5D0FF0@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <e950cde8-8cd9-6089-c833-23d2ffb539d1@linux.intel.com>
> From: Lu Baolu [mailto:baolu.lu@linux.intel.com]
> Sent: Friday, October 25, 2019 10:39 PM
>
> Hi,
>
> On 10/25/19 2:40 PM, Tian, Kevin wrote:
> >>>> ioasid_register_allocator(&iommu->pasid_allocator);
> >>>> + if (ret) {
> >>>> + pr_warn("Custom PASID allocator
> >>>> registeration failed\n");
> >>>> + /*
> >>>> + * Disable scalable mode on this
> >>>> IOMMU if there
> >>>> + * is no custom allocator. Mixing
> >>>> SM capable vIOMMU
> >>>> + * and non-SM vIOMMU are not
> >>>> supported.
> >>>> + */
> >>>> + intel_iommu_sm = 0;
> >>> It's insufficient to disable scalable mode by only clearing
> >>> intel_iommu_sm. The DMA_RTADDR_SMT bit in root entry has already
> >> been
> >>> set. Probably, you need to
> >>>
> >>> for each iommu
> >>> clear DMA_RTADDR_SMT in root entry
> >>>
> >>> Alternatively, since vSVA is the only customer of this custom PASID
> >>> allocator, is it possible to only disable SVA here?
> >>>
> >> Yeah, I think disable SVA is better. We can still do gIOVA in SM. I
> >> guess we need to introduce a flag for sva_enabled.
> > I'm not sure whether tying above logic to SVA is the right approach.
> > If vcmd interface doesn't work, the whole SM mode doesn't make
> > sense which is based on PASID-granular protection (SVA is only one
> > usage atop). If the only remaining usage of SM is to map gIOVA using
> > reserved PASID#0, then why not disabling SM and just fallback to
> > legacy mode?
> >
> > Based on that I prefer to disabling the SM mode completely (better
> > through an interface), and move the logic out of CONFIG_INTEL_
> > IOMMU_SVM
> >
>
> Unfortunately, it is dangerous to disable SM after boot. SM uses
> different root/device contexts and pasid table formats. Disabling SM
> after boot requires changing above from SM format into legacy format.
You are correct.
>
> Since ioasid registration failure is a rare case. How about moving this
> part of code up to the early stage of intel_iommu_init() and returning
> error if hardware present vcmd capability but software fails to register
> a custom ioasid allocator?
>
It makes sense to me.
Thanks
Kevin
next prev parent reply other threads:[~2019-10-25 15:52 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-24 19:54 [PATCH v7 00/11] Nested Shared Virtual Address (SVA) VT-d support Jacob Pan
2019-10-24 19:54 ` [PATCH v7 01/11] iommu/vt-d: Cache virtual command capability register Jacob Pan
2019-10-25 2:53 ` Lu Baolu
2019-10-25 6:06 ` Tian, Kevin
2019-11-08 10:32 ` Auger Eric
2019-10-24 19:54 ` [PATCH v7 02/11] iommu/vt-d: Enlightened PASID allocation Jacob Pan
2019-10-25 6:19 ` Tian, Kevin
2019-10-29 17:14 ` Jacob Pan
2019-10-29 18:16 ` Tian, Kevin
2019-11-08 10:33 ` Auger Eric
2019-11-08 22:22 ` Jacob Pan
2019-10-24 19:54 ` [PATCH v7 03/11] iommu/vt-d: Add custom allocator for IOASID Jacob Pan
2019-10-25 2:30 ` Lu Baolu
2019-10-25 4:43 ` Jacob Pan
2019-10-25 6:40 ` Tian, Kevin
2019-10-25 14:39 ` Lu Baolu
2019-10-25 15:52 ` Tian, Kevin [this message]
2019-10-28 22:49 ` Jacob Pan
2019-10-29 2:22 ` Lu Baolu
2019-10-25 6:31 ` Tian, Kevin
2019-10-28 22:52 ` Jacob Pan
2019-11-08 10:40 ` Auger Eric
2019-11-08 22:26 ` Jacob Pan
2019-10-24 19:54 ` [PATCH v7 04/11] iommu/vt-d: Replace Intel specific PASID allocator with IOASID Jacob Pan
2019-10-25 5:47 ` Lu Baolu
2019-11-01 18:29 ` Jacob Pan
2019-10-25 6:41 ` Tian, Kevin
2019-10-28 22:46 ` Jacob Pan
2019-11-08 11:30 ` Auger Eric
2019-11-08 22:55 ` Jacob Pan
2019-11-12 9:54 ` Auger Eric
2019-10-24 19:54 ` [PATCH v7 05/11] iommu/vt-d: Move domain helper to header Jacob Pan
2019-10-25 5:26 ` Lu Baolu
2019-10-24 19:54 ` [PATCH v7 06/11] iommu/vt-d: Avoid duplicated code for PASID setup Jacob Pan
2019-10-25 5:32 ` Lu Baolu
2019-10-25 6:42 ` Tian, Kevin
2019-10-28 22:41 ` Jacob Pan
2019-11-12 9:54 ` Auger Eric
2019-10-24 19:55 ` [PATCH v7 07/11] iommu/vt-d: Add nested translation helper function Jacob Pan
2019-10-25 7:04 ` Tian, Kevin
2019-11-01 21:10 ` Jacob Pan
2019-10-25 15:04 ` Lu Baolu
2019-10-25 16:06 ` Jacob Pan
2019-11-08 13:55 ` Auger Eric
2019-10-24 19:55 ` [PATCH v7 08/11] iommu/vt-d: Misc macro clean up for SVM Jacob Pan
2019-10-26 1:00 ` Lu Baolu
2019-10-28 22:38 ` Jacob Pan
2019-10-24 19:55 ` [PATCH v7 09/11] iommu/vt-d: Add bind guest PASID support Jacob Pan
2019-10-25 7:19 ` Tian, Kevin
2019-10-25 17:33 ` Jacob Pan
2019-10-28 6:03 ` Tian, Kevin
2019-10-28 16:02 ` Jacob Pan
2019-10-29 7:57 ` Tian, Kevin
2019-10-29 16:11 ` Jacob Pan
2019-10-29 18:04 ` Tian, Kevin
2019-10-29 2:33 ` Lu Baolu
2019-10-26 2:01 ` Lu Baolu
2019-10-28 22:29 ` Jacob Pan
2019-10-29 2:54 ` Lu Baolu
2019-10-29 4:11 ` Jacob Pan
2019-10-29 5:04 ` Lu Baolu
2019-10-24 19:55 ` [PATCH v7 10/11] iommu/vt-d: Support flushing more translation cache types Jacob Pan
2019-10-25 7:21 ` Tian, Kevin
2019-11-01 21:30 ` Jacob Pan
2019-10-26 2:22 ` Lu Baolu
2019-11-01 21:28 ` Jacob Pan
2019-11-08 16:18 ` Auger Eric
2019-11-08 23:05 ` Jacob Pan
2019-10-24 19:55 ` [PATCH v7 11/11] iommu/vt-d: Add svm/sva invalidate function Jacob Pan
2019-10-25 7:27 ` Tian, Kevin
2019-10-26 2:40 ` Lu Baolu
2019-10-26 7:03 ` Lu Baolu
2019-10-28 6:06 ` Tian, Kevin
2019-10-28 16:10 ` Jacob Pan
2019-10-29 18:52 ` Tian, Kevin
2019-10-29 19:25 ` Jacob Pan
2019-10-28 16:13 ` Jacob Pan
2019-11-12 10:28 ` Auger Eric
2020-02-15 1:18 ` Jacob Pan
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=AADFC41AFE54684AB9EE6CBC0274A5D19D5D0FF0@SHSMSX104.ccr.corp.intel.com \
--to=kevin.tian@intel.com \
--cc=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=baolu.lu@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=eric.auger@redhat.com \
--cc=hch@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@linux.intel.com \
--cc=jean-philippe@linaro.com \
--cc=jic23@kernel.org \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.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).