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.