On Wed, 5 Jun 2019 08:51:45 +0000 "Tian, Kevin" <kevin.t...@intel.com> wrote:
> > From: Jacob Pan > > Sent: Tuesday, June 4, 2019 6:09 AM > > > > On Mon, 3 Jun 2019 15:57:47 +0100 > > Jean-Philippe Brucker <jean-philippe.bruc...@arm.com> wrote: > > > > > +/** > > > + * struct iommu_fault_page_request - Page Request data > > > + * @flags: encodes whether the corresponding fields are valid and > > > whether this > > > + * is the last page in group (IOMMU_FAULT_PAGE_REQUEST_* > > > values) > > > + * @pasid: Process Address Space ID > > > + * @grpid: Page Request Group Index > > > + * @perm: requested page permissions (IOMMU_FAULT_PERM_* values) > > > + * @addr: page address > > > + * @private_data: device-specific private information > > > + */ > > > +struct iommu_fault_page_request { > > > +#define IOMMU_FAULT_PAGE_REQUEST_PASID_VALID (1 << 0) > > > +#define IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE (1 << 1) > > > +#define IOMMU_FAULT_PAGE_REQUEST_PRIV_DATA (1 << 2) > > > + __u32 flags; > > > + __u32 pasid; > > > + __u32 grpid; > > > + __u32 perm; > > > + __u64 addr; > > > + __u64 private_data[2]; > > > +}; > > > + > > > > Just a thought, for non-identity G-H PASID management. We could > > pass on guest PASID in PRQ to save a lookup in QEMU. In this case, > > QEMU allocate a GPASID for vIOMMU then a host PASID for pIOMMU. > > QEMU has a G->H lookup. When PRQ comes in to the pIOMMU with > > HPASID, IOMMU driver > > can retrieve GPASID from the bind data then report to the guest via > > VFIO. In this case QEMU does not need to do a H->G PASID lookup. > > > > Should we add a gpasid field here? or we can add a flag and field > > later, up to you. > > > > Can private_data serve this purpose? It's better not introducing > gpasid awareness within host IOMMU driver. It is just a user-level > data associated with a PASID when binding happens. Kernel doesn't > care the actual meaning, simply record it and then return back to > user space later upon device fault. Qemu interprets the meaning as > gpasid in its own context. otherwise usages may use it for other > purpose. > private_data was intended for device PRQ with private data, part of the VT-d PRQ descriptor. For vSVA, we can withhold private_data in the host then respond back when page response from the guest matches pending PRQ with the data withheld. But for in-kernel PRQ reporting, private data still might be passed on to any driver who wants to process the PRQ. So we can't re-purpose it. But for in-kernel VDCM driver, it needs a lookup from guest PASID to host PASID. I thought you wanted to have IOMMU driver provide such service since the knowledge of H-G pasid can be established during bind_gpasid time. In that sense, we _do_ have gpasid awareness. > Thanks > Kevin [Jacob Pan] _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu