> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Thursday, September 5, 2024 8:01 PM > > On Tue, Sep 03, 2024 at 05:59:38PM -0700, Dan Williams wrote: > > Jason Gunthorpe wrote: > > > It would be a good starting point for other platforms to pick at. Try > > > iommufd first (I'm guessing this is correct) and if it doesn't work > > > explain why. > > > > Yes, makes sense. Will take a look at that also to prevent more > > disconnects on what this PCI device-security community is actually > > building. > > We are already adding a VIOMMU object and that is going to be the > linkage to the KVM side > > So we could have new actions: > - Create a CC VIOMMU with XYZ parameters > - Create a CC vPCI function on the vIOMMU with XYZ parameters > - Query stuff? > - ??? > - Destroy a vPCI function > I'll look at the vIOMMU series soon. Just double confirm here. the so-called vIOMMU object here is the uAPI between iommufd and userspace. Not exactly suggesting a vIOMMU visible to guest. otherwise this solution will be tied to implementations supporting trusted vIOMMU. Then you expect to build CC/vPCI stuff around the vIOMMU object given it already connects to KVM?
