在 2021/4/6 上午7:42, Jason Gunthorpe 写道:
On Fri, Apr 02, 2021 at 08:22:28AM +0000, Tian, Kevin wrote:
From: Jason Gunthorpe <jgg@xxxxxxxxxx>
Sent: Tuesday, March 30, 2021 9:29 PM
First, userspace may use ioasid in a non-SVA scenario where ioasid is
bound to specific security context (e.g. a control vq in vDPA) instead of
tying to mm. In this case there is no pgtable binding initiated from user
space. Instead, ioasid is allocated from /dev/ioasid and then programmed
to the intended security context through specific passthrough framework
which manages that context.
This sounds like the exact opposite of what I'd like to see.
I do not want to see every subsystem gaining APIs to program a
PASID. All of that should be consolidated in *one place*.
I do not want to see VDPA and VFIO have two nearly identical sets of
APIs to control the PASID.
Drivers consuming a PASID, like VDPA, should consume the PASID and do
nothing more than authorize the HW to use it.
quemu should have general code under the viommu driver that drives
/dev/ioasid to create PASID's and manage the IO mapping according to
the guest's needs.
Drivers like VDPA and VFIO should simply accept that PASID and
configure/authorize their HW to do DMA's with its tag.
I agree with you on consolidating things in one place (especially for the
general SVA support). But here I was referring to an usage without
pgtable binding (Possibly Jason. W can say more here), where the
userspace just wants to allocate PASIDs, program/accept PASIDs to
various workqueues (device specific), and then use MAP/UNMAP
interface to manage address spaces associated with each PASID.
I just wanted to point out that the latter two steps are through
VFIO/VDPA specific interfaces.
No, don't do that.
VFIO and VDPA has no buisness having map/unmap interfaces once we have
/dev/ioasid. That all belongs in the iosaid side.
I know they have those interfaces today, but that doesn't mean we have
to keep using them for PASID use cases, they should be replaced with a
'do dma from this pasid on /dev/ioasid' interface certainly not a
'here is a pasid from /dev/ioasid, go ahead and configure it youself'
interface
So it looks like the PASID was bound to SVA in this design. I think it's
not necessairly the case:
1) PASID can be implemented without SVA, in this case a map/unmap
interface is still required
2) For the case that hypervisor want to do some mediation in the middle
for a virtqueue. e.g in the case of control vq that is implemented in
the VF/ADI/SF itself, the hardware virtqueue needs to be controlled by
Qemu, Though binding qemu's page table to cvq can work but it looks like
a overkill, a small dedicated buffers that is mapped for this PASID
seems more suitalbe.
This is because PASID is *complicated* in the general case! For
instance all the two level stuff you are talking about must not leak
into every user!
Jason
So do you mean the device should not expose the PASID confiugration API
to guest? I think it could happen if we assign the whole device and let
guest to configure it for nested VMs.
Thanks
