From: Stefan Hajnoczi <stefanha@redhat.com>
To: kvm@vger.kernel.org
Cc: David Laight <David.Laight@ACULAB.COM>,
linux-kernel@vger.kernel.org, "Tian,
Kevin" <kevin.tian@intel.com>,
Alex Williamson <alex.williamson@redhat.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
Stefan Hajnoczi <stefanha@redhat.com>,
Jason Gunthorpe <jgg@nvidia.com>
Subject: [PATCH v2 1/3] vfio: trivially use __aligned_u64 for ioctl structs
Date: Tue, 29 Aug 2023 14:27:18 -0400 [thread overview]
Message-ID: <20230829182720.331083-2-stefanha@redhat.com> (raw)
In-Reply-To: <20230829182720.331083-1-stefanha@redhat.com>
u64 alignment behaves differently depending on the architecture and so
<uapi/linux/types.h> offers __aligned_u64 to achieve consistent behavior
in kernel<->userspace ABIs.
There are structs in <uapi/linux/vfio.h> that can trivially be updated
to __aligned_u64 because the struct sizes are multiples of 8 bytes.
There is no change in memory layout on any CPU architecture and
therefore this change is safe.
The commits that follow this one handle the trickier cases where
explanation about ABI breakage is necessary.
Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
include/uapi/linux/vfio.h | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index f9c6f3e2cf6e..94007ca348ed 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -277,8 +277,8 @@ struct vfio_region_info {
#define VFIO_REGION_INFO_FLAG_CAPS (1 << 3) /* Info supports caps */
__u32 index; /* Region index */
__u32 cap_offset; /* Offset within info struct of first cap */
- __u64 size; /* Region size (bytes) */
- __u64 offset; /* Region offset from start of device fd */
+ __aligned_u64 size; /* Region size (bytes) */
+ __aligned_u64 offset; /* Region offset from start of device fd */
};
#define VFIO_DEVICE_GET_REGION_INFO _IO(VFIO_TYPE, VFIO_BASE + 8)
@@ -294,8 +294,8 @@ struct vfio_region_info {
#define VFIO_REGION_INFO_CAP_SPARSE_MMAP 1
struct vfio_region_sparse_mmap_area {
- __u64 offset; /* Offset of mmap'able area within region */
- __u64 size; /* Size of mmap'able area */
+ __aligned_u64 offset; /* Offset of mmap'able area within region */
+ __aligned_u64 size; /* Size of mmap'able area */
};
struct vfio_region_info_cap_sparse_mmap {
@@ -450,9 +450,9 @@ struct vfio_device_migration_info {
VFIO_DEVICE_STATE_V1_RESUMING)
__u32 reserved;
- __u64 pending_bytes;
- __u64 data_offset;
- __u64 data_size;
+ __aligned_u64 pending_bytes;
+ __aligned_u64 data_offset;
+ __aligned_u64 data_size;
};
/*
@@ -476,7 +476,7 @@ struct vfio_device_migration_info {
struct vfio_region_info_cap_nvlink2_ssatgt {
struct vfio_info_cap_header header;
- __u64 tgt;
+ __aligned_u64 tgt;
};
/*
@@ -1443,7 +1443,7 @@ struct vfio_iommu_type1_info {
__u32 flags;
#define VFIO_IOMMU_INFO_PGSIZES (1 << 0) /* supported page sizes info */
#define VFIO_IOMMU_INFO_CAPS (1 << 1) /* Info supports caps */
- __u64 iova_pgsizes; /* Bitmap of supported page sizes */
+ __aligned_u64 iova_pgsizes; /* Bitmap of supported page sizes */
__u32 cap_offset; /* Offset within info struct of first cap */
__u32 pad;
};
--
2.41.0
next prev parent reply other threads:[~2023-08-29 18:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-29 18:27 [PATCH v2 0/3] vfio: use __aligned_u64 for ioctl structs Stefan Hajnoczi
2023-08-29 18:27 ` Stefan Hajnoczi [this message]
2023-08-31 8:45 ` [PATCH v2 1/3] vfio: trivially " Philippe Mathieu-Daudé
2023-09-11 6:06 ` Tian, Kevin
2023-08-29 18:27 ` [PATCH v2 2/3] vfio: use __aligned_u64 in struct vfio_device_gfx_plane_info Stefan Hajnoczi
2023-09-07 16:25 ` Jason Gunthorpe
2023-09-11 6:07 ` Tian, Kevin
2023-09-15 20:04 ` Alex Williamson
2023-09-18 14:15 ` Stefan Hajnoczi
2023-08-29 18:27 ` [PATCH v2 3/3] vfio: use __aligned_u64 in struct vfio_device_ioeventfd Stefan Hajnoczi
2023-09-11 6:08 ` Tian, Kevin
2023-08-29 21:10 ` [PATCH v2 0/3] vfio: use __aligned_u64 for ioctl structs David Laight
2023-08-30 8:32 ` David Laight
2023-08-30 21:53 ` Stefan Hajnoczi
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=20230829182720.331083-2-stefanha@redhat.com \
--to=stefanha@redhat.com \
--cc=David.Laight@ACULAB.COM \
--cc=alex.williamson@redhat.com \
--cc=jgg@nvidia.com \
--cc=jgg@ziepe.ca \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox