Comment 0 for bug 1878514

Description

To support live migration of mediated device assignment with SVM/SVA, guest must have its own PASID namespace.
Our first implementation of SVM uses system wide PASID allocation scheme which is not live migration friendly.
Proposed by Kevin Tian and Yi Liu from virtualization team, we need to add extensions to IOMMU guest SVA bind APIs. The work flow is as follows:

Here is a flow if QEMU chooses to do non-identity mapping of G-H PASID.
1. Guest does sva_bind_mm()
2. Guest calls vcmd, qemu returns guest PASID, allocate host pasid from host IOMMU driver, QEMU maintains G->H PASID lookup.
3. Guest IOMMU driver programs GPASID entry, then do PASID cache invalidate
4. QEMU traps PASID cache flush, find matching host PASID with mapping from #2
5. Host IOMMU driver does bind_gpasid(hpasid, gpasid, dev), maintains H->G PASID lookup in host IOMMU driver
6. Guest programs mdev DWQ with GPASID, trapped in QEMU then VDCM
7. VDCM calls the newly proposed iommu_get_hpasid() API to do G->H lookup established in #5 (reverse), then program hpasid in HW.

PRQ:
1. Host IOMMU receives PRQ with hpasid
2. Host IOMMU looks up guest PASID (which is in private data as part of the gpasid bind), Reports PRQ fault with host PASID with guest PASID as private data(avoid reverse lookup in QEMU on performance path)
3. QEMU receives PRQ with host PASID, obtain guest PASID from fault private data

PR response
1. Guest send page response with guest PASID
2. QEMU does G->H PASID look up
3. QEMU passdown page response with host PASID

Note:
- Fast lookup directions
- QEMU does G->H lookup
- IOMMU driver does H->G lookup

- Reverse lookup
- IOMMU driver does G->H reverse look up only for slow path

Target Release: 20.10
Target Kernel: 5.9