linux-kernel - Re: [PATCH v7 1/3] iommufd: Add data structure for Intel VT-d stage-1 cache invalidation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240104143658.GX50406@nvidia.com>
Date: Thu, 4 Jan 2024 10:36:58 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Yi Liu <yi.l.liu@...el.com>
Cc: joro@...tes.org, alex.williamson@...hat.com, kevin.tian@...el.com,
	robin.murphy@....com, baolu.lu@...ux.intel.com, cohuck@...hat.com,
	eric.auger@...hat.com, nicolinc@...dia.com, kvm@...r.kernel.org,
	mjrosato@...ux.ibm.com, chao.p.peng@...ux.intel.com,
	yi.y.sun@...ux.intel.com, peterx@...hat.com, jasowang@...hat.com,
	shameerali.kolothum.thodi@...wei.com, lulu@...hat.com,
	suravee.suthikulpanit@....com, iommu@...ts.linux.dev,
	linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
	zhenzhong.duan@...el.com, joao.m.martins@...cle.com,
	xin.zeng@...el.com, yan.y.zhao@...el.com
Subject: Re: [PATCH v7 1/3] iommufd: Add data structure for Intel VT-d
 stage-1 cache invalidation

On Thu, Dec 14, 2023 at 07:26:39PM +0800, Yi Liu wrote:
> Per the prior discussion[1], we agreed to move the error reporting into the
> driver specific part. On Intel side, we want to report two devTLB
> invalidation errors: ICE (invalid completion error) and ITE (invalidation
> timeout error). Such errors have an additional SID information to tell
> which device failed the devTLB invalidation. I've got the below structure.

IMHO all of this complexity is a consequence of the decision to hide
the devtlb invalidation from the VM..

On the other hand I guess you want to do this because of the SIOV
troubles where the vPCI function in the VM is entirely virtual and
can't be trivially mapped to a real PCI function for ATC invalidation
like ARM and AMD can do (but they also can't support SIOV because of
this). :(

However it also makes it very confusing about how the VM would
perceive an error - eg if it invalidates an SIOV device single PASID
and that devtlb fails then the error should be connected back to the
vPCI function for the SIOV's specific PASID and not back to the
physical PCI function for the SIOV owner.

As the iommu driver itself has no idea about the vPCI functions this
seems like it is going to get really confusing. The API I suggested in
the other email is not entirely going to work as the vPCI function for
SIOV cases will have to be identified by the (struct device, PASID) -
while it would be easy enough for the iommu driver to provide the
PASID, I'm not sure how the iommufd core will relate the PASID back to
the iommu_device to understand SIOV without actually being aware of
SIOV to some degree :\

(Given SIOVr1 seems on track to be replaced by SIOVr2 so this is all a
one-off I was hoping to minimize such awareness)

Jason