On Fri, Oct 04, 2024 at 01:33:33PM -0700, Nicolin Chen wrote:
On Fri, Oct 04, 2024 at 05:17:46PM -0300, Jason Gunthorpe wrote:
On Fri, Oct 04, 2024 at 12:25:19PM -0700, Nicolin Chen wrote:
With that, I wonder what is better for the initial version of this structure, a generic virtual ID or a driver-named ID like "Stream ID"? The latter might be more understandable/flexible, so we won't need to justify a generic virtual ID along the way if something changes in the nature?
I think the name could be a bit more specific "viommu_device_id" maybe? And elaborate in the kdoc that this is about the identifier that the iommu HW itself uses.
A "vIOMMU Device ID" might sound a bit confusing with an ID of a vIOMMU itself :-/
At this moment, I named it "virt_id" in uAPI with a description: " * @virt_id: Virtual device ID per vIOMMU"
I could add to that (or just in the documentation): "e.g. ARM's Stream ID, AMD's DeviceID, Intel's Context Table ID" to clarify it further.
Yeah probably best
Alexey is working on vIOMMU support in CC which has the trusted world do some of the trusted vIOMMU components. I'm hoping the other people in this area will look at his design and make it fit nicely to everyone.
Oh, I didn't connect the dots that lowervisor must rely on the vIOMMU too -- I'd need to check the CC stuff in detail. In that case, having it in vIOMMU uAPI totally makes sense.
I think we are still getting through this, and I do wonder how to manage it with so much stuff still in flux and sometimes private.
At least for AMD's CC case where there is an entanglement with the physical IOMMU it seems like it makes sense.
Even in the pKVM type case I think you end up ripping the translation away from the "physical" iommu and there should be some coordination to ensure this handover is clean and undone when iommufd is closed. But I wonder how the S2 works there..
Jason