From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Nicolin Chen <nicolinc@nvidia.com>,
"Liu, Yi L" <yi.l.liu@intel.com>,
"joro@8bytes.org" <joro@8bytes.org>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"robin.murphy@arm.com" <robin.murphy@arm.com>,
"baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
"cohuck@redhat.com" <cohuck@redhat.com>,
"eric.auger@redhat.com" <eric.auger@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"mjrosato@linux.ibm.com" <mjrosato@linux.ibm.com>,
"chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>,
"yi.y.sun@linux.intel.com" <yi.y.sun@linux.intel.com>,
"peterx@redhat.com" <peterx@redhat.com>,
"jasowang@redhat.com" <jasowang@redhat.com>,
"shameerali.kolothum.thodi@huawei.com"
<shameerali.kolothum.thodi@huawei.com>,
"lulu@redhat.com" <lulu@redhat.com>,
"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-kselftest@vger.kernel.org"
<linux-kselftest@vger.kernel.org>,
"Duan, Zhenzhong" <zhenzhong.duan@intel.com>,
"Martins, Joao" <joao.m.martins@oracle.com>
Subject: RE: [PATCH v4 08/17] iommufd: Always setup MSI and anforce cc on kernel-managed domains
Date: Tue, 17 Oct 2023 08:52:49 +0000 [thread overview]
Message-ID: <BN9PR11MB5276FDC375685CE04A7AD93B8CD6A@BN9PR11MB5276.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20231016115736.GP3952@nvidia.com>
> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Monday, October 16, 2023 7:58 PM
>
> On Mon, Oct 16, 2023 at 08:48:03AM +0000, Tian, Kevin wrote:
> > > From: Nicolin Chen <nicolinc@nvidia.com>
> > > Sent: Saturday, October 14, 2023 8:45 AM
> > >
> > > On Tue, Sep 26, 2023 at 01:16:35AM -0700, Tian, Kevin wrote:
> > > > > From: Liu, Yi L <yi.l.liu@intel.com>
> > > > > Sent: Thursday, September 21, 2023 3:51 PM
> > > > >
> > > > > From: Nicolin Chen <nicolinc@nvidia.com>
> > > > >
> > > > > Now enforce_cache_coherency and msi_cookie are kernel-managed
> hwpt
> > > > > things.
> > > > > So, they should be only setup on kernel-managed domains. If the
> > > attaching
> > > > > domain is a user-managed domain, redirect the hwpt to hwpt->parent
> to
> > > do
> > > > > it correctly.
> > > > >
> > > >
> > > > No redirection. The parent should already have the configuration done
> > > > when it's created. It shouldn't be triggered in the nesting path.
> > >
> > > iommufd_hw_pagetable_enforce_cc() is not only called in alloc(),
> > > but also in hwpt_attach/replace() if cc is not enforced by the
> > > alloc() because the idev that initiates the hwpt_alloc() might
> > > not have idev->enforce_cache_coherency. Only when another idev
> > > that has idev->enforce_cache_coherency attaches to the shared
> > > hwpt, the cc configuration would be done.
> >
> > is this a bug already? If the 1st device doesn't have enforce_cc in its
> > iommu, setting the snp bit in the hwpt would lead to reserved
> > bit violation.
>
> I suspect there are technically some gaps in the intel driver, yes..
double checked. intel driver is doing right thing now:
intel_iommu_enforce_cache_coherency()
domain_support_force_snooping()
static bool domain_support_force_snooping(struct dmar_domain *domain)
{
struct device_domain_info *info;
bool support = true;
assert_spin_locked(&domain->lock);
list_for_each_entry(info, &domain->devices, link) {
if (!ecap_sc_support(info->iommu->ecap)) {
support = false;
break;
}
}
return support;
}
>
> > another problem is that intel_iommu_enforce_cache_coherency()
> > doesn't update existing entries. It only sets a domain flag to affect
> > future mappings. so it means the 2nd idev is also broken.
>
> This is such a gap, intel driver should not permit that.
yes. @Baolu, can you add a fix?
>
> > The simplest option is to follow vfio type1 i.e. don't mix devices
> > with different enforce_cc in one domain.
>
> This is why I wanted to get rid of this bad mechanism going forward.
>
> Manually created hwpt should have a manual specification of cc and
> then we don't have so many problems.
>
> It means userspace needs to compute if they want to use CC or not, but
> userspace already needs to figure this out since without autodomains
> it must create two hwpts manually anyhow.
>
Now there is no interface reporting enforce_cc to userspace.
Actually the user doesn't need to know enforce_cc. As long as there is
an attach incompatibility error the user has to create a 2nd hwpt for
the to-be-attached device then enforce_cc will be handled automatically
in hwpt_alloc.
I prefer to removing enforce_cc in attach fn completely then no parent
trick in this patch. Just keep it in hwpt_alloc and leave to iommu driver to
figure out the attaching compatibility:
- attaching a idev with matching enforce_cc as hwpt is always allowed.
- attaching a idev w/o enforce_cc to a hwpt with enforce_cc is rejected.
- attaching a idev w/ enforce_cc to a hwpt w/o enforce_cc succeeds with
hwpt continuing to be w/o enforce_cc. No promotion.
above has been guaranteed by intel iommu driver.
next prev parent reply other threads:[~2023-10-17 8:53 UTC|newest]
Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-21 7:51 [PATCH v4 00/17] iommufd: Add nesting infrastructure Yi Liu
2023-09-21 7:51 ` [PATCH v4 01/17] iommu: Add hwpt_type with user_data for domain_alloc_user op Yi Liu
2023-09-21 12:10 ` Baolu Lu
2023-09-21 20:58 ` Nicolin Chen
2023-09-25 13:05 ` Jason Gunthorpe
2023-09-25 18:17 ` Nicolin Chen
2023-09-25 6:22 ` Yi Liu
2023-09-25 8:01 ` Baolu Lu
2023-09-25 13:00 ` Jason Gunthorpe
2023-09-21 12:12 ` Baolu Lu
2023-09-21 16:44 ` Jason Gunthorpe
2023-09-22 9:47 ` Robin Murphy
2023-09-25 6:17 ` Yi Liu
2023-09-25 12:59 ` Jason Gunthorpe
2023-09-26 6:37 ` Tian, Kevin
2023-09-26 16:29 ` Jason Gunthorpe
2023-09-27 1:08 ` Tian, Kevin
2023-10-07 9:38 ` Yi Liu
2023-09-26 6:56 ` Tian, Kevin
2023-10-12 9:12 ` Yi Liu
2023-10-13 11:42 ` Yi Liu
2023-10-13 22:22 ` Nicolin Chen
2023-10-10 16:58 ` Jason Gunthorpe
2023-10-12 9:11 ` Yi Liu
2023-10-12 13:39 ` Jason Gunthorpe
2023-10-13 4:33 ` Yi Liu
2023-10-13 14:04 ` Jason Gunthorpe
2023-10-13 17:56 ` Nicolin Chen
2023-10-16 3:28 ` Yi Liu
2023-10-16 11:54 ` Jason Gunthorpe
2023-10-16 18:17 ` Nicolin Chen
2023-10-17 8:51 ` Yi Liu
2023-10-17 9:28 ` Tian, Kevin
2023-10-18 6:12 ` Yi Liu
2023-10-18 16:37 ` Jason Gunthorpe
2023-10-18 16:51 ` Nicolin Chen
2023-10-13 0:34 ` Nicolin Chen
2023-10-13 14:03 ` Jason Gunthorpe
2023-09-21 7:51 ` [PATCH v4 02/17] iommu: Add nested domain support Yi Liu
2023-10-10 17:21 ` Jason Gunthorpe
2023-10-12 9:13 ` Yi Liu
2023-10-14 0:47 ` Nicolin Chen
2023-09-21 7:51 ` [PATCH v4 03/17] iommufd: Unite all kernel-managed members into a struct Yi Liu
2023-09-26 7:46 ` Tian, Kevin
2023-10-07 10:08 ` Yan Zhao
2023-10-09 4:13 ` Yi Liu
2023-10-09 5:13 ` Yan Zhao
2023-10-10 3:26 ` Yi Liu
2023-09-21 7:51 ` [PATCH v4 04/17] iommufd: Pass in hwpt_type/user_data to iommufd_hw_pagetable_alloc() Yi Liu
2023-09-21 7:51 ` [PATCH v4 05/17] iommufd: Separate kernel-managed HWPT alloc/destroy/abort functions Yi Liu
2023-09-26 7:57 ` Tian, Kevin
2023-10-10 18:49 ` Jason Gunthorpe
2023-10-12 19:09 ` Jason Gunthorpe
2023-10-13 7:13 ` Tian, Kevin
2023-10-13 14:05 ` Jason Gunthorpe
2023-10-16 8:26 ` Tian, Kevin
2023-10-16 12:02 ` Jason Gunthorpe
2023-09-21 7:51 ` [PATCH v4 06/17] iommufd: Add shared alloc_fn function pointer and mutex pointer Yi Liu
2023-09-21 7:51 ` [PATCH v4 07/17] iommufd: Add user-managed hw_pagetable support Yi Liu
2023-09-26 8:14 ` Tian, Kevin
2023-10-14 0:08 ` Nicolin Chen
2023-09-21 7:51 ` [PATCH v4 08/17] iommufd: Always setup MSI and anforce cc on kernel-managed domains Yi Liu
2023-09-26 8:16 ` Tian, Kevin
2023-10-14 0:44 ` Nicolin Chen
2023-10-16 8:48 ` Tian, Kevin
2023-10-16 11:57 ` Jason Gunthorpe
2023-10-17 8:52 ` Tian, Kevin [this message]
2023-10-17 15:53 ` Jason Gunthorpe
2023-10-17 19:58 ` Nicolin Chen
2023-10-18 16:51 ` Jason Gunthorpe
2023-10-19 1:56 ` Tian, Kevin
2023-10-19 23:53 ` Jason Gunthorpe
2023-10-20 2:43 ` Tian, Kevin
2023-10-20 13:55 ` Jason Gunthorpe
2023-10-20 18:59 ` Nicolin Chen
2023-10-21 16:38 ` Jason Gunthorpe
2023-10-23 0:18 ` Nicolin Chen
2023-10-23 2:53 ` Tian, Kevin
2023-10-23 18:42 ` Nicolin Chen
2023-10-23 13:59 ` Jason Gunthorpe
2023-10-23 18:49 ` Nicolin Chen
2023-10-18 2:32 ` Baolu Lu
2023-10-17 9:05 ` Tian, Kevin
2023-09-21 7:51 ` [PATCH v4 09/17] iommufd/device: Add helpers to enforce/remove device reserved regions Yi Liu
2023-10-07 7:20 ` Yan Zhao
2023-10-07 9:27 ` Nicolin Chen
2023-09-21 7:51 ` [PATCH v4 10/17] iommufd: Support IOMMU_HWPT_ALLOC allocation with user data Yi Liu
2023-10-13 15:19 ` Jason Gunthorpe
2023-10-13 20:58 ` Nicolin Chen
2023-10-14 0:07 ` Jason Gunthorpe
2023-10-14 0:51 ` Nicolin Chen
2023-10-16 7:03 ` Yi Liu
2023-10-16 11:59 ` Jason Gunthorpe
2023-10-16 18:44 ` Nicolin Chen
2023-10-17 8:55 ` Yi Liu
2023-10-17 15:50 ` Jason Gunthorpe
2023-10-17 19:32 ` Nicolin Chen
2023-09-21 7:51 ` [PATCH v4 11/17] iommufd: Add IOMMU_HWPT_INVALIDATE Yi Liu
2023-09-21 7:51 ` [PATCH v4 12/17] iommufd/selftest: Rework TEST_LENGTH to test min_size explicitly Yi Liu
2023-09-21 7:51 ` [PATCH v4 13/17] iommufd/selftest: Add nested domain allocation for mock domain Yi Liu
2023-09-21 7:51 ` [PATCH v4 14/17] iommufd/selftest: Add coverage for IOMMU_HWPT_ALLOC with nested HWPTs Yi Liu
2023-09-21 7:51 ` [PATCH v4 15/17] iommufd/selftest: Add mock_domain_cache_invalidate_user support Yi Liu
2023-09-21 7:51 ` [PATCH v4 16/17] iommufd/selftest: Add IOMMU_TEST_OP_MD_CHECK_IOTLB test op Yi Liu
2023-09-21 7:51 ` [PATCH v4 17/17] iommufd/selftest: Add coverage for IOMMU_HWPT_INVALIDATE ioctl Yi Liu
2023-10-10 16:53 ` [PATCH v4 00/17] iommufd: Add nesting infrastructure Jason Gunthorpe
2023-10-12 8:45 ` Yi Liu
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=BN9PR11MB5276FDC375685CE04A7AD93B8CD6A@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=cohuck@redhat.com \
--cc=eric.auger@redhat.com \
--cc=iommu@lists.linux.dev \
--cc=jasowang@redhat.com \
--cc=jgg@nvidia.com \
--cc=joao.m.martins@oracle.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=lulu@redhat.com \
--cc=mjrosato@linux.ibm.com \
--cc=nicolinc@nvidia.com \
--cc=peterx@redhat.com \
--cc=robin.murphy@arm.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=yi.l.liu@intel.com \
--cc=yi.y.sun@linux.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 NNTP newsgroup(s).