Received: by 2002:a05:7412:37c9:b0:e2:908c:2ebd with SMTP id jz9csp387569rdb; Mon, 18 Sep 2023 20:08:58 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGnjDglq5xTGC5/afzW5GxgB7eoBwztbS7imzwJHpZ6UiMZwAqhNmm2v7EaUIabrtjQ+3oZ X-Received: by 2002:a17:90a:760b:b0:273:f887:be17 with SMTP id s11-20020a17090a760b00b00273f887be17mr10579495pjk.47.1695092937627; Mon, 18 Sep 2023 20:08:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695092937; cv=none; d=google.com; s=arc-20160816; b=Q04qV43ZMW66h0Q/ndcsbTCd6Ft0QXM0wzE37CTXalu6XydzBx9wfU0Mi+9t4q+kwm +TyBW6TLslXNUe0J4zlDPeDxME1UYjQ/NsGN7HnwFReA9J0mmcv1GN+J5AQ5VT/gsKnP N6HtSrBb0+xU0BOk1bSmKy3WFjPgdUHxmSunuFIeHFIjnqDjs9KxhbY2g/GEw3HOsMvH vhA78eXJFpcLBjuOy5vQYsKR9Wbcdw0p+qDNpSQc6l24dCZzLNvjqiWbeYCGSXZAEJoc 4g8PULt3BbfYsCspyc+odKvz5bCT4NU8WC/pCi3BAvrt8NXmgJL8RyKB4uJgZRi73jpx mZMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=BLJVBc/pzccugePJdqT4Or41HsOp/4DxwdzX8mZIktY=; fh=rtm8eCWQTZN1DdtHrlyuNr29zexmVCqfq1PTVUama8o=; b=fCaYvUPT7y0ZmaluqGDE6r37YGCLcxrX7lvKdZd2Dpxb4kK2VLU0sYN0mTYKDOfYcg Rj0s0yjTt1CydY8eh5PreWxDKrODsmXDcGvs0DZRQrAxpgifF+juaoo5pCDdpZfHn7MD vZkVxrSIDakWlClyFfC5l/ZLRVHWBhpVXd19h5o1Ar4FiEjRcg/try7XJmdLqVauwpBy ZRCkssjV7jSU9HcEt8189qgwaHTFtwoEc9SR3X6oWRkRyEN33iFjgDrw+JmKIQTegun4 yt4/tqYwrsUMz0vLTyKZcuhIxio3YpAmYGw+YY5iW2QZVn9lSwQm/LJkTbriq5YQw2hf zpIg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="X4+SNYw/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id ot4-20020a17090b3b4400b00274ea3cb558si3814713pjb.80.2023.09.18.20.08.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Sep 2023 20:08:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="X4+SNYw/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 10BAF823EF2E; Mon, 18 Sep 2023 13:57:29 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230098AbjIRU5W (ORCPT + 99 others); Mon, 18 Sep 2023 16:57:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52184 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230078AbjIRU5R (ORCPT ); Mon, 18 Sep 2023 16:57:17 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B3483115 for ; Mon, 18 Sep 2023 13:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695070587; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BLJVBc/pzccugePJdqT4Or41HsOp/4DxwdzX8mZIktY=; b=X4+SNYw/FuXqUJ4KyJkwYfzOVVERp8CdeJrzw2X/vg1+QF+6x392KRuvxKiUBhvPdOGco0 BOW9aiyNHiHqdfNZv4DhYSNYmbxzRUx/rfwT2y7BIQdbNhQJ8xwiGbBCsdXoq54WsC8vwr VQdDUYWmWH5lVu1I+iDb1edFDUJWjkE= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-150-CjqjOcAdPzOEQ4KcAmIYmg-1; Mon, 18 Sep 2023 16:56:22 -0400 X-MC-Unique: CjqjOcAdPzOEQ4KcAmIYmg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 96B51800883; Mon, 18 Sep 2023 20:56:21 +0000 (UTC) Received: from localhost (unknown [10.39.195.53]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1BD9040C2064; Mon, 18 Sep 2023 20:56:20 +0000 (UTC) From: Stefan Hajnoczi To: kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Jason Gunthorpe , Alex Williamson , David Laight , "Tian, Kevin" , Stefan Hajnoczi , Jason Gunthorpe , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= Subject: [PATCH v3 1/3] vfio: trivially use __aligned_u64 for ioctl structs Date: Mon, 18 Sep 2023 16:56:15 -0400 Message-ID: <20230918205617.1478722-2-stefanha@redhat.com> In-Reply-To: <20230918205617.1478722-1-stefanha@redhat.com> References: <20230918205617.1478722-1-stefanha@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Mon, 18 Sep 2023 13:57:29 -0700 (PDT) u64 alignment behaves differently depending on the architecture and so offers __aligned_u64 to achieve consistent behavior in kernel<->userspace ABIs. There are structs in 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 Reviewed-by: Jason Gunthorpe Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Kevin Tian Signed-off-by: Stefan Hajnoczi --- 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 afc1369216d9..4dc0182c6bcb 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; }; /* @@ -1449,7 +1449,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