On Thu, 16 May 2019 15:14:40 +0100
Jean-Philippe Brucker <jean-philippe.bruc...@arm.com> wrote:
> Hi Jacob,
>
> On 03/05/2019 23:32, Jacob Pan wrote:
> > +/**
> > + * struct gpasid_bind_data - Information about device and guest
> > PASID binding
> > + * @gcr3: Guest CR3 value from guest mm
> > + * @pasid: Process address space ID used for the guest mm
> > + * @addr_width: Guest address width. Paging mode can also
> > be derived.
> > + */
> > +struct gpasid_bind_data {
> > + __u64 gcr3;
> > + __u32 pasid;
> > + __u32 addr_width;
> > + __u32 flags;
> > +#define IOMMU_SVA_GPASID_SRE BIT(0) /* supervisor
> > request */
> > + __u8 padding[4];
> > +};
>
> Could you wrap this structure into a generic one like we now do for
> bind_pasid_table? It would make the API easier to extend, because if
> we ever add individual PASID bind on Arm (something I'd like to do for
> virtio-iommu, eventually) it will have different parameters, as our
> PASID table entry has a lot of fields describing the page table
> format.
>
> Maybe something like the following would do?
>
> struct gpasid_bind_data {
> #define IOMMU_GPASID_BIND_VERSION_1 1
> __u32 version;
> #define IOMMU_GPASID_BIND_FORMAT_INTEL_VTD 1
> __u32 format;
> union {
> // the current gpasid_bind_data:
> struct gpasid_bind_intel_vtd vtd;
> };
> };
>
OK, sounds great.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
