Messages in this thread | | | From | "Tian, Kevin" <> | Subject | RE: [PATCH v4 08/17] iommufd: Always setup MSI and anforce cc on kernel-managed domains | Date | Mon, 16 Oct 2023 08:48:03 +0000 |
| |
> 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.
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.
The simplest option is to follow vfio type1 i.e. don't mix devices with different enforce_cc in one domain.
| |