From: Jacob Pan <jacob.jun.pan@linux.intel.com> To: Joerg Roedel <joro@8bytes.org>, Alex Williamson <alex.williamson@redhat.com>, "Lu Baolu" <baolu.lu@linux.intel.com>, iommu@lists.linux-foundation.org, LKML <linux-kernel@vger.kernel.org>, David Woodhouse <dwmw2@infradead.org>, Jean-Philippe Brucker <jean-philippe@linaro.com> Cc: "Yi Liu" <yi.l.liu@intel.com>, "Tian, Kevin" <kevin.tian@intel.com>, Raj Ashok <ashok.raj@intel.com>, Eric Auger <eric.auger@redhat.com>, Jacob Pan <jacob.jun.pan@linux.intel.com> Subject: [PATCH v2 1/3] iommu/uapi: Define uapi version and capabilities Date: Wed, 25 Mar 2020 16:17:05 -0700 [thread overview] Message-ID: <1585178227-17061-2-git-send-email-jacob.jun.pan@linux.intel.com> (raw) In-Reply-To: <1585178227-17061-1-git-send-email-jacob.jun.pan@linux.intel.com> Having a single UAPI version to govern the user-kernel data structures makes compatibility check straightforward. On the contrary, supporting combinations of multiple versions of the data can be a nightmare to maintain. This patch defines a unified UAPI version to be used for compatibility checks between user and kernel. --- v2: Rewrite extension rules to disallow adding new members. Use padding and union extensions only. --- Signed-off-by: Liu Yi L <yi.l.liu@intel.com> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Link: https://lkml.org/lkml/2020/2/3/1126 --- include/uapi/linux/iommu.h | 53 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) diff --git a/include/uapi/linux/iommu.h b/include/uapi/linux/iommu.h index d7bcbc5f79b0..25dba9198d7f 100644 --- a/include/uapi/linux/iommu.h +++ b/include/uapi/linux/iommu.h @@ -8,6 +8,59 @@ #include <linux/types.h> +/** + * Current version of the IOMMU user API. This is intended for query + * between user and kernel to determine compatible data structures. + * + * UAPI version can be bumped up with the following rules: + * 1. All data structures passed between user and kernel space share + * the same version number. i.e. any extension to any structure + * results in version number increment. + * + * 2. Data structures are open to extension but closed to modification. + * Extensions are allowed in two places: + * - the padding bytes with a flag bit for each new member + * - new union members at the end of each structure + * + * No new members can be added after padding bytes are exhausted. + * The reason is that the union size can change when new members are + * added, having new member at the end would break backward + * compatibility. Expansion of the union would move the new member + * to different offset between versions. + * + * Flag bits can be added without size change but existing ones + * cannot be altered. + * + * 3. Versions are backward compatible. + * + * 4. Version to size lookup is supported by kernel internal API for each + * API function type. @version is mandatory for new data structures + * and must be at the beginning with type of __u32. + */ +#define IOMMU_UAPI_VERSION 1 +static inline int iommu_get_uapi_version(void) +{ + return IOMMU_UAPI_VERSION; +} + +/* + * Supported UAPI features that can be reported to user space. + * These types represent the capability available in the kernel. + * + * REVISIT: UAPI version also implies the capabilities. Should we + * report them explicitly? + */ +enum IOMMU_UAPI_DATA_TYPES { + IOMMU_UAPI_BIND_GPASID, + IOMMU_UAPI_CACHE_INVAL, + IOMMU_UAPI_PAGE_RESP, + NR_IOMMU_UAPI_TYPE, +}; + +#define IOMMU_UAPI_CAP_MASK ((1 << IOMMU_UAPI_BIND_GPASID) | \ + (1 << IOMMU_UAPI_CACHE_INVAL) | \ + (1 << IOMMU_UAPI_PAGE_RESP)) + #define IOMMU_FAULT_PERM_READ (1 << 0) /* read */ #define IOMMU_FAULT_PERM_WRITE (1 << 1) /* write */ #define IOMMU_FAULT_PERM_EXEC (1 << 2) /* exec */ -- 2.7.4
WARNING: multiple messages have this Message-ID (diff)
From: Jacob Pan <jacob.jun.pan@linux.intel.com> To: Joerg Roedel <joro@8bytes.org>, Alex Williamson <alex.williamson@redhat.com>, "Lu Baolu" <baolu.lu@linux.intel.com>, iommu@lists.linux-foundation.org, LKML <linux-kernel@vger.kernel.org>, David Woodhouse <dwmw2@infradead.org>, Jean-Philippe Brucker <jean-philippe@linaro.com> Cc: "Tian, Kevin" <kevin.tian@intel.com>, Raj Ashok <ashok.raj@intel.com> Subject: [PATCH v2 1/3] iommu/uapi: Define uapi version and capabilities Date: Wed, 25 Mar 2020 16:17:05 -0700 [thread overview] Message-ID: <1585178227-17061-2-git-send-email-jacob.jun.pan@linux.intel.com> (raw) In-Reply-To: <1585178227-17061-1-git-send-email-jacob.jun.pan@linux.intel.com> Having a single UAPI version to govern the user-kernel data structures makes compatibility check straightforward. On the contrary, supporting combinations of multiple versions of the data can be a nightmare to maintain. This patch defines a unified UAPI version to be used for compatibility checks between user and kernel. --- v2: Rewrite extension rules to disallow adding new members. Use padding and union extensions only. --- Signed-off-by: Liu Yi L <yi.l.liu@intel.com> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Link: https://lkml.org/lkml/2020/2/3/1126 --- include/uapi/linux/iommu.h | 53 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) diff --git a/include/uapi/linux/iommu.h b/include/uapi/linux/iommu.h index d7bcbc5f79b0..25dba9198d7f 100644 --- a/include/uapi/linux/iommu.h +++ b/include/uapi/linux/iommu.h @@ -8,6 +8,59 @@ #include <linux/types.h> +/** + * Current version of the IOMMU user API. This is intended for query + * between user and kernel to determine compatible data structures. + * + * UAPI version can be bumped up with the following rules: + * 1. All data structures passed between user and kernel space share + * the same version number. i.e. any extension to any structure + * results in version number increment. + * + * 2. Data structures are open to extension but closed to modification. + * Extensions are allowed in two places: + * - the padding bytes with a flag bit for each new member + * - new union members at the end of each structure + * + * No new members can be added after padding bytes are exhausted. + * The reason is that the union size can change when new members are + * added, having new member at the end would break backward + * compatibility. Expansion of the union would move the new member + * to different offset between versions. + * + * Flag bits can be added without size change but existing ones + * cannot be altered. + * + * 3. Versions are backward compatible. + * + * 4. Version to size lookup is supported by kernel internal API for each + * API function type. @version is mandatory for new data structures + * and must be at the beginning with type of __u32. + */ +#define IOMMU_UAPI_VERSION 1 +static inline int iommu_get_uapi_version(void) +{ + return IOMMU_UAPI_VERSION; +} + +/* + * Supported UAPI features that can be reported to user space. + * These types represent the capability available in the kernel. + * + * REVISIT: UAPI version also implies the capabilities. Should we + * report them explicitly? + */ +enum IOMMU_UAPI_DATA_TYPES { + IOMMU_UAPI_BIND_GPASID, + IOMMU_UAPI_CACHE_INVAL, + IOMMU_UAPI_PAGE_RESP, + NR_IOMMU_UAPI_TYPE, +}; + +#define IOMMU_UAPI_CAP_MASK ((1 << IOMMU_UAPI_BIND_GPASID) | \ + (1 << IOMMU_UAPI_CACHE_INVAL) | \ + (1 << IOMMU_UAPI_PAGE_RESP)) + #define IOMMU_FAULT_PERM_READ (1 << 0) /* read */ #define IOMMU_FAULT_PERM_WRITE (1 << 1) /* write */ #define IOMMU_FAULT_PERM_EXEC (1 << 2) /* exec */ -- 2.7.4 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-03-25 23:11 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-25 23:17 [PATCH v2 0/3] IOMMU user API enhancement Jacob Pan 2020-03-25 23:17 ` Jacob Pan 2020-03-25 23:17 ` Jacob Pan [this message] 2020-03-25 23:17 ` [PATCH v2 1/3] iommu/uapi: Define uapi version and capabilities Jacob Pan 2020-03-26 9:23 ` Christoph Hellwig 2020-03-26 9:23 ` Christoph Hellwig 2020-03-26 16:44 ` Jacob Pan 2020-03-26 16:44 ` Jacob Pan 2020-03-27 2:49 ` Tian, Kevin 2020-03-27 2:49 ` Tian, Kevin 2020-03-27 7:47 ` Christoph Hellwig 2020-03-27 7:47 ` Christoph Hellwig 2020-03-27 23:53 ` Jacob Pan 2020-03-27 23:53 ` Jacob Pan 2020-03-30 5:40 ` Tian, Kevin 2020-03-30 5:40 ` Tian, Kevin 2020-03-30 16:07 ` Jacob Pan 2020-03-30 16:07 ` Jacob Pan 2020-03-31 6:06 ` Tian, Kevin 2020-03-31 6:06 ` Tian, Kevin 2020-03-31 15:54 ` Jacob Pan 2020-03-31 15:54 ` Jacob Pan 2020-04-01 5:32 ` Tian, Kevin 2020-04-01 5:32 ` Tian, Kevin 2020-04-02 18:36 ` Jacob Pan 2020-04-02 18:36 ` Jacob Pan 2020-04-13 20:41 ` Jacob Pan 2020-04-13 20:41 ` Jacob Pan 2020-04-13 22:21 ` Alex Williamson 2020-04-13 22:21 ` Alex Williamson 2020-04-14 5:05 ` Jacob Pan 2020-04-14 5:05 ` Jacob Pan 2020-04-14 16:13 ` Alex Williamson 2020-04-14 16:13 ` Alex Williamson 2020-04-14 17:13 ` Jacob Pan 2020-04-14 17:13 ` Jacob Pan 2020-04-14 22:32 ` Jacob Pan 2020-04-14 22:32 ` Jacob Pan 2020-04-14 23:47 ` Tian, Kevin 2020-04-14 23:47 ` Tian, Kevin 2020-04-15 15:38 ` Jacob Pan 2020-04-15 15:38 ` Jacob Pan 2020-04-16 1:27 ` Tian, Kevin 2020-04-16 1:27 ` Tian, Kevin 2020-04-14 8:15 ` Christoph Hellwig 2020-04-14 8:15 ` Christoph Hellwig 2020-04-14 8:11 ` Christoph Hellwig 2020-04-14 8:11 ` Christoph Hellwig 2020-04-14 16:06 ` Jacob Pan 2020-04-14 16:06 ` Jacob Pan 2020-03-25 23:17 ` [PATCH v2 2/3] iommu/uapi: Use unified UAPI version Jacob Pan 2020-03-25 23:17 ` Jacob Pan 2020-03-25 23:17 ` [PATCH v2 3/3] iommu/uapi: Add helper function for size lookup Jacob Pan 2020-03-25 23:17 ` 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=1585178227-17061-2-git-send-email-jacob.jun.pan@linux.intel.com \ --to=jacob.jun.pan@linux.intel.com \ --cc=alex.williamson@redhat.com \ --cc=ashok.raj@intel.com \ --cc=baolu.lu@linux.intel.com \ --cc=dwmw2@infradead.org \ --cc=eric.auger@redhat.com \ --cc=iommu@lists.linux-foundation.org \ --cc=jean-philippe@linaro.com \ --cc=joro@8bytes.org \ --cc=kevin.tian@intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=yi.l.liu@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: linkBe 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.