From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 70715C433B4 for ; Thu, 29 Apr 2021 16:08:35 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 109616146D for ; Thu, 29 Apr 2021 16:08:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 109616146D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=6zlyyLFqNg6RmE/JtX15WqyvF/fcWUKIolxmYsimbIo=; b=eh1oyFrv+qdXR1/5bg1wdtYLQ ID6gfvuufPLig+LVVM0RRR6ohgF4up9Tx+vZF9E/vWVa1VqU3BLCl0SY34XIr70tEu12BQ1u3IXBw XhdA7/jEHtKOeHw26cxLQ2dVdmvIHwg6nXinvxmeI1kgjIoqwsJmQGBzVYG75aKtABffugb08eJYQ lZXitz1Xe2rVr+maoEwma640Tf5We/yTIrpbU3aQYsP/U373Z09jffkQFklEJPxGLmthqg1zzZ6hf xE1qxTkTfqRh0wsiHE/Vya+tDCjqG2apQMxC2Au3EGT6sDSCep800NS/EGLbNtUKG5dcub5lgE+/V u7EEffuyA==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lc9Bi-0061aT-C8; Thu, 29 Apr 2021 16:06:50 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lc9BK-0061Yo-KO for linux-arm-kernel@desiato.infradead.org; Thu, 29 Apr 2021 16:06:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To: Subject:Sender:Reply-To:Content-ID:Content-Description; bh=JBeLiMg7iq7gfKcB9LhjWfT8azY0d2eBiMT+KTH1PiU=; b=uwCch2z3FC9mvXVsDB/Tk83bqo /f8WXmG10vsSb2lXwkL5oUY4uOoFxXKVKm7NhIRmrTVq4w/wcxYe9Gc0M70x/0ZzE+hB6nRxP+ceN 1n6y1gJxzNxtNImiMBxQKI1PgPGyaUUISKulYuptt6YwoTlmFcBbJaVP4/3VvqHlIo8FChJk9J+/b mdEXRzc9gC33PwdjKhG23ui7cnsIM0YL93J6w3sxREZ6u4xOk9rWK51yf+ub3n0b3pfsTFXMBI+CU H26k8Zdxz4sKn33RhoqdN6ZO9lAqXkErsvDU7DNmS70/q+vdDA+0z5dqpfy2uh2xaWVoQjnBPkO2U N2NZXE/Q==; Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lc9BI-000kNw-0Y for linux-arm-kernel@lists.infradead.org; Thu, 29 Apr 2021 16:06:25 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4E3DB101E; Thu, 29 Apr 2021 09:06:15 -0700 (PDT) Received: from [192.168.1.179] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9BDBB3F85F; Thu, 29 Apr 2021 09:06:12 -0700 (PDT) Subject: Re: [PATCH v11 5/6] KVM: arm64: ioctl to fetch/store tags in a guest To: Catalin Marinas Cc: Marc Zyngier , Will Deacon , James Morse , Julien Thierry , Suzuki K Poulose , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Dave Martin , Mark Rutland , Thomas Gleixner , qemu-devel@nongnu.org, Juan Quintela , "Dr. David Alan Gilbert" , Richard Henderson , Peter Maydell , Haibo Xu , Andrew Jones References: <20210416154309.22129-1-steven.price@arm.com> <20210416154309.22129-6-steven.price@arm.com> <20210427175844.GB17872@arm.com> From: Steven Price Message-ID: <340d35c2-46ed-35ea-43fa-e5cb64c27230@arm.com> Date: Thu, 29 Apr 2021 17:06:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210427175844.GB17872@arm.com> Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210429_090624_130609_6C412F64 X-CRM114-Status: GOOD ( 20.69 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 27/04/2021 18:58, Catalin Marinas wrote: > On Fri, Apr 16, 2021 at 04:43:08PM +0100, Steven Price wrote: >> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h >> index 24223adae150..2b85a047c37d 100644 >> --- a/arch/arm64/include/uapi/asm/kvm.h >> +++ b/arch/arm64/include/uapi/asm/kvm.h >> @@ -184,6 +184,20 @@ struct kvm_vcpu_events { >> __u32 reserved[12]; >> }; >> >> +struct kvm_arm_copy_mte_tags { >> + __u64 guest_ipa; >> + __u64 length; >> + union { >> + void __user *addr; >> + __u64 padding; >> + }; >> + __u64 flags; >> + __u64 reserved[2]; >> +}; > > I know Marc asked for some reserved space in here but I'm not sure it's > the right place. And what's with the union of a 64-bit pointer and > 64-bit padding, it doesn't change any layout? Yes it's unnecessary here - habits die hard. This would ensure that the layout is the same for 32 bit and 64 bit. But it's irrelevant here as (a) we don't support 32 bit, and (b) flags has 64 bit alignment anyway. I'll drop the union (and 'padding'). > Maybe add the two reserved > values to the union in case we want to store something else in the > future. I'm not sure what you mean here. What would the reserved fields be unioned with? And surely they are no longer reserved in that case? > Or maybe I'm missing something, I haven't checked how other KVM ioctls > work. KVM ioctls seem to (sometimes) have some reserved space at the end of the structure for expansion without the ioctl number changing (since the structure size is encoded into the ioctl). Steve _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel