On 2024/8/14 15:38, Tian, Kevin wrote:
From: Liu, Yi L <yi.l.liu@xxxxxxxxx>
Sent: Wednesday, August 14, 2024 2:39 PM
On 2024/8/6 22:20, Jason Gunthorpe wrote:
On Mon, Aug 05, 2024 at 05:35:17AM +0000, Tian, Kevin wrote:
Okay. With that I edited my earlier reply a bit by removing the note
of cmdline option, adding DVSEC possibility, and making it clear that
the PASID option is in vIOMMU:
"
Overall this sounds a feasible path to move forward - starting with
the VMM to find the gap automatically if PASID is opted in vIOMMU.
Devices with hidden registers may fail. Devices with volatile
config space due to FW upgrade or cross vendors may fail to migrate.
Then evolving it to the file-based scheme, and there is time to discuss
any intermediate improvement (fixed quirks, DVSEC, etc.) in between.
"
Jason, your thoughts?
This thread is big and I've read it quickly, but I could support the
above summary.
thanks for the ideas. I think we still need a uapi to report if the device
supports PASID or not. Do we have agreement on where should this uapi be
defined? vfio or iommufd.
IOMMUFD_CMD_GET_HW_INFO.
Hi Kevin, Jason,
In order to synthesize the vPASID cap, the VMM should get to know the
capabilities like Privilege mode, Execute permission from the physical
device's config space. We have two choices as well. vfio or iommufd.
It appears to be better reporting the capabilities via vfio uapi (e.g.
VFIO_DEVICE_FEATURE). If we want to go through iommufd, then we need to
add a pair of data_uptr/data_size fields in the GET_HW_INFO to report the
PASID capabilities to userspace. Please let me know your preference. :)
--
Regards,
Yi Liu
