From: Joerg Roedel <joro@8bytes.org>
To: Jacob Pan <jacob.pan.linux@gmail.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
Raj Ashok <ashok.raj@intel.com>, Jonathan Corbet <corbet@lwn.net>,
Jean-Philippe Brucker <jean-philippe@linaro.com>,
Alex Williamson <alex.williamson@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
iommu@lists.linux-foundation.org, Wu Hao <hao.wu@intel.com>,
David Woodhouse <dwmw2@infradead.org>,
Yi Sun <yi.y.sun@intel.com>
Subject: Re: [PATCH v9 3/7] iommu/uapi: Introduce enum type for PASID data format
Date: Fri, 18 Sep 2020 11:44:50 +0200 [thread overview]
Message-ID: <20200918094450.GP31590@8bytes.org> (raw)
In-Reply-To: <1599861476-53416-4-git-send-email-jacob.jun.pan@linux.intel.com>
On Fri, Sep 11, 2020 at 02:57:52PM -0700, Jacob Pan wrote:
> There can be multiple vendor-specific PASID data formats used in UAPI
> structures. This patch adds enum type with a last entry which makes
> range checking much easier.
But it also makes it much easier to screw up the numbers (which are ABI)
by inserting a new value into the middle. I prefer defines here, or
alternativly BUILD_BUG_ON() checks for the numbers.
Regards,
Joerg
>
> Suggested-by: Alex Williamson <alex.williamson@redhat.com>
> Reviewed-by: Eric Auger <eric.auger@redhat.com>
> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
> ---
> include/uapi/linux/iommu.h | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/include/uapi/linux/iommu.h b/include/uapi/linux/iommu.h
> index b42acc8fe007..7cc6ee6c41f7 100644
> --- a/include/uapi/linux/iommu.h
> +++ b/include/uapi/linux/iommu.h
> @@ -298,11 +298,16 @@ struct iommu_gpasid_bind_data_vtd {
> IOMMU_SVA_VTD_GPASID_PCD | \
> IOMMU_SVA_VTD_GPASID_PWT)
>
> +enum iommu_pasid_data_format {
> + IOMMU_PASID_FORMAT_INTEL_VTD = 1,
> + IOMMU_PASID_FORMAT_LAST,
> +};
> +
> /**
> * struct iommu_gpasid_bind_data - Information about device and guest PASID binding
> * @argsz: User filled size of this data
> * @version: Version of this data structure
> - * @format: PASID table entry format
> + * @format: PASID table entry format of enum iommu_pasid_data_format type
> * @flags: Additional information on guest bind request
> * @gpgd: Guest page directory base of the guest mm to bind
> * @hpasid: Process address space ID used for the guest mm in host IOMMU
> @@ -321,7 +326,6 @@ struct iommu_gpasid_bind_data {
> __u32 argsz;
> #define IOMMU_GPASID_BIND_VERSION_1 1
> __u32 version;
> -#define IOMMU_PASID_FORMAT_INTEL_VTD 1
> __u32 format;
> __u32 addr_width;
> #define IOMMU_SVA_GPASID_VAL (1 << 0) /* guest PASID valid */
> --
> 2.7.4
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <joro@8bytes.org>
To: Jacob Pan <jacob.pan.linux@gmail.com>
Cc: iommu@lists.linux-foundation.org,
LKML <linux-kernel@vger.kernel.org>,
Alex Williamson <alex.williamson@redhat.com>,
Lu Baolu <baolu.lu@linux.intel.com>,
David Woodhouse <dwmw2@infradead.org>,
Jonathan Corbet <corbet@lwn.net>,
Jean-Philippe Brucker <jean-philippe@linaro.com>,
Eric Auger <eric.auger@redhat.com>,
Jacob Pan <jacob.jun.pan@linux.intel.com>,
Yi Liu <yi.l.liu@intel.com>, "Tian, Kevin" <kevin.tian@intel.com>,
Raj Ashok <ashok.raj@intel.com>, Wu Hao <hao.wu@intel.com>,
Yi Sun <yi.y.sun@intel.com>
Subject: Re: [PATCH v9 3/7] iommu/uapi: Introduce enum type for PASID data format
Date: Fri, 18 Sep 2020 11:44:50 +0200 [thread overview]
Message-ID: <20200918094450.GP31590@8bytes.org> (raw)
In-Reply-To: <1599861476-53416-4-git-send-email-jacob.jun.pan@linux.intel.com>
On Fri, Sep 11, 2020 at 02:57:52PM -0700, Jacob Pan wrote:
> There can be multiple vendor-specific PASID data formats used in UAPI
> structures. This patch adds enum type with a last entry which makes
> range checking much easier.
But it also makes it much easier to screw up the numbers (which are ABI)
by inserting a new value into the middle. I prefer defines here, or
alternativly BUILD_BUG_ON() checks for the numbers.
Regards,
Joerg
>
> Suggested-by: Alex Williamson <alex.williamson@redhat.com>
> Reviewed-by: Eric Auger <eric.auger@redhat.com>
> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
> ---
> include/uapi/linux/iommu.h | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/include/uapi/linux/iommu.h b/include/uapi/linux/iommu.h
> index b42acc8fe007..7cc6ee6c41f7 100644
> --- a/include/uapi/linux/iommu.h
> +++ b/include/uapi/linux/iommu.h
> @@ -298,11 +298,16 @@ struct iommu_gpasid_bind_data_vtd {
> IOMMU_SVA_VTD_GPASID_PCD | \
> IOMMU_SVA_VTD_GPASID_PWT)
>
> +enum iommu_pasid_data_format {
> + IOMMU_PASID_FORMAT_INTEL_VTD = 1,
> + IOMMU_PASID_FORMAT_LAST,
> +};
> +
> /**
> * struct iommu_gpasid_bind_data - Information about device and guest PASID binding
> * @argsz: User filled size of this data
> * @version: Version of this data structure
> - * @format: PASID table entry format
> + * @format: PASID table entry format of enum iommu_pasid_data_format type
> * @flags: Additional information on guest bind request
> * @gpgd: Guest page directory base of the guest mm to bind
> * @hpasid: Process address space ID used for the guest mm in host IOMMU
> @@ -321,7 +326,6 @@ struct iommu_gpasid_bind_data {
> __u32 argsz;
> #define IOMMU_GPASID_BIND_VERSION_1 1
> __u32 version;
> -#define IOMMU_PASID_FORMAT_INTEL_VTD 1
> __u32 format;
> __u32 addr_width;
> #define IOMMU_SVA_GPASID_VAL (1 << 0) /* guest PASID valid */
> --
> 2.7.4
next prev parent reply other threads:[~2020-09-18 9:44 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-11 21:57 [PATCH v9 0/7] IOMMU user API enhancement Jacob Pan
2020-09-11 21:57 ` Jacob Pan
2020-09-11 21:57 ` [PATCH v9 1/7] docs: IOMMU user API Jacob Pan
2020-09-11 21:57 ` Jacob Pan
2020-09-16 18:26 ` Randy Dunlap
2020-09-16 18:26 ` Randy Dunlap
2020-09-18 19:44 ` Jacob Pan
2020-09-11 21:57 ` [PATCH v9 2/7] iommu/uapi: Add argsz for user filled data Jacob Pan
2020-09-11 21:57 ` Jacob Pan
2020-09-11 21:57 ` [PATCH v9 3/7] iommu/uapi: Introduce enum type for PASID data format Jacob Pan
2020-09-11 21:57 ` Jacob Pan
2020-09-18 9:44 ` Joerg Roedel [this message]
2020-09-18 9:44 ` Joerg Roedel
2020-09-18 17:11 ` Jacob Pan
2020-09-22 20:24 ` Jacob Pan
2020-09-22 20:24 ` Jacob Pan
2020-09-24 8:40 ` Joerg Roedel
2020-09-24 8:40 ` Joerg Roedel
2020-09-24 18:31 ` Jacob Pan
2020-09-24 18:31 ` Jacob Pan
2020-09-11 21:57 ` [PATCH v9 4/7] iommu/uapi: Use named union for user data Jacob Pan
2020-09-11 21:57 ` Jacob Pan
2020-09-11 21:57 ` [PATCH v9 5/7] iommu/uapi: Rename uapi functions Jacob Pan
2020-09-11 21:57 ` Jacob Pan
2020-09-11 21:57 ` [PATCH v9 6/7] iommu/uapi: Handle data and argsz filled by users Jacob Pan
2020-09-11 21:57 ` Jacob Pan
2020-09-11 21:57 ` [PATCH v9 7/7] iommu/vt-d: Check UAPI data processed by IOMMU core Jacob Pan
2020-09-11 21:57 ` Jacob Pan
2020-09-18 10:02 ` [PATCH v9 0/7] IOMMU user API enhancement Joerg Roedel
2020-09-18 10:02 ` Joerg Roedel
2020-09-18 17:26 ` Jacob Pan
2020-09-18 17:26 ` Jacob Pan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200918094450.GP31590@8bytes.org \
--to=joro@8bytes.org \
--cc=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=corbet@lwn.net \
--cc=dwmw2@infradead.org \
--cc=hao.wu@intel.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.pan.linux@gmail.com \
--cc=jean-philippe@linaro.com \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=yi.y.sun@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.