[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d652546a-c6ca-1cc6-1924-b016bd81a792@arm.com>
Date: Thu, 16 May 2019 15:14:40 +0100
From: Jean-Philippe Brucker <jean-philippe.brucker@....com>
To: Jacob Pan <jacob.jun.pan@...ux.intel.com>,
iommu@...ts.linux-foundation.org,
LKML <linux-kernel@...r.kernel.org>,
Joerg Roedel <joro@...tes.org>,
David Woodhouse <dwmw2@...radead.org>,
Eric Auger <eric.auger@...hat.com>,
Alex Williamson <alex.williamson@...hat.com>
Cc: "Tian, Kevin" <kevin.tian@...el.com>,
Raj Ashok <ashok.raj@...el.com>,
Andriy Shevchenko <andriy.shevchenko@...ux.intel.com>
Subject: Re: [PATCH v3 09/16] iommu: Introduce guest PASID bind function
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;
};
};
Thanks,
Jean
Powered by blists - more mailing lists