On 2020/9/16 上午3:26, Raj, Ashok wrote:
IIUC, you are asking that part of the interface to move to a API interface
that potentially the new /dev/sva and VFIO could share? I think the API's
for PASID management themselves are generic (Jean's patchset + Jacob's
ioasid set management).
Yes, the in kernel APIs are pretty generic now, and can be used by
many types of drivers.
Good, so there is no new requirements here I suppose.
The requirement is not for in-kernel APIs but a generic uAPIs.
As JasonW kicked this off, VDPA will need all this identical stuff
too. We already know this, and I think Intel VDPA HW will need it, so
it should concern you too:)
This is one of those things that I would disagree and commit :-)..
A PASID vIOMMU solution sharable with VDPA and VFIO, based on a PASID
control char dev (eg /dev/sva, or maybe /dev/iommu) seems like a
reasonable starting point for discussion.
Looks like now we are getting closer to what we need.:-)
Given that PASID api's are general purpose today and any driver can use it
to take advantage. VFIO fortunately or unfortunately has the IOMMU things
abstracted. I suppose that support is also mostly built on top of the
generic iommu* api abstractions in a vendor neutral way?
I'm still lost on what is missing that vDPA can't build on top of what is
available?
For sure it can, but we may end up duplicated (or similar) uAPIs which
is bad.
Thanks
Cheers,
Ashok
