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. > That sounds wider than what I defined it for in my patch: > * struct iommu_vdevice_alloc - ioctl(IOMMU_VDEVICE_ALLOC) > * ... > * Allocate a virtual device instance (for a physical device) against a vIOMMU. > * This instance holds the device's information in a VM, related to its vIOMMU. > > Would you please help rephrase it? It'd be also helpful for me > to update the doc. I think that is still OK for the moment. > Though I feel slightly odd if we define it wider than "vIOMMU" > since this is an iommufd header... The notion I have is that vIOMMU would expand to encompass not just the physical hypervisor controled vIOMMU but also the vIOMMU controlled by the trusted "lowervisor" in a pkvm/cc/whatever world. 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. Jason
