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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E7F70C001DE for ; Mon, 31 Jul 2023 09:30:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 359596B0085; Mon, 31 Jul 2023 05:30:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 30A2A6B0087; Mon, 31 Jul 2023 05:30:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D17A28001A; Mon, 31 Jul 2023 05:30:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 0E3D46B0085 for ; Mon, 31 Jul 2023 05:30:52 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id D01FD1A0AD5 for ; Mon, 31 Jul 2023 09:30:51 +0000 (UTC) X-FDA: 81071387502.22.1FBEA6E Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) by imf03.hostedemail.com (Postfix) with ESMTP id E48B820026 for ; Mon, 31 Jul 2023 09:30:48 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=guIUa9Tp; spf=pass (imf03.hostedemail.com: domain of qperret@google.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=qperret@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690795849; a=rsa-sha256; cv=none; b=W+AmJL+QyBCNxDvZnGQLRGcbXCnOYXVejS2IBgr0IpruKCxgu3+m+F6ltmxKwYgB/oksSY 9EJlSledMqJdhRaPa8TW1ON/BE+IlgyOkxP5sY64By8S4Zl0BfFHa64WgiOXzFOBr5uceI LUpsy3d8F4yBvtPF/eQODzDhBt1IiUo= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=guIUa9Tp; spf=pass (imf03.hostedemail.com: domain of qperret@google.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=qperret@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690795849; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ziEHdMiDKlKGEA4myzpOfHCTiCmmAiAT9VETtxXexS8=; b=7SsncpK/4KEY2wQPGSPf3czAg9JsbF05DqvCyfoURdg2YsAAyJL61IW6UZeHsRwSCvEoEt vxbJM9s8joAIlaj1qCCGEGzNi6qOew4Vw3kZJz0+2gD4eiGbO/Mm5V9PXdzeIj7zWdEB9J K5hQRlfPDPhaYUr5+e8rnBAMSV2QhWg= Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-52256241c50so6798204a12.3 for ; Mon, 31 Jul 2023 02:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1690795847; x=1691400647; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ziEHdMiDKlKGEA4myzpOfHCTiCmmAiAT9VETtxXexS8=; b=guIUa9TpRYBjI0stX0rR0q2KYRVdgo42Rwix6s3W6cxhGOSx6PVyCTdA5g/AS2h33d qccXGdTTxsaL3dKPpzdUGCwz9sOnNjZP2QZ+IRlflzPGUckJBW/eFq4DipVJqbUG5NQ/ 5teoOLbLNLvidR0nDX0dInMVzU60IzUEZpiCJ78DCgLwH4VDVpyvS+PFDJmp2H2Cqsaq ckd8/Aqk96/l2tM08ubMYTGsra64KF4plRKJW4CV/d6dRMYvZWy3I0q2vTBh3JUMjdY2 e0xEUNA9wJufu3+8SkFanLOhloqOVlBS3eZCjfmk+1nbmTk3VOjLRNz4/M5kaTwNZDzq GaNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690795847; x=1691400647; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ziEHdMiDKlKGEA4myzpOfHCTiCmmAiAT9VETtxXexS8=; b=Y4R087RJOsWvrexC96LM7pIC/oiOwwORsm0byNcw4UvnKlO+eUh25D61HLY6Bb1PDq TiDy82SFv4fr5Voj/2nEWqzh0s8A04YvQ9DO49kdqFPVMkJEgzGGEwJIZ3Ni0timQSqI fAauOUcXjrpZNVM8+YwGkg31uI00EhrPXpehi7p6AuEvg3gWlPEjtw0ajGSS3tWL5zhB fqQJP/34b7hcJEBLyCxFYC47L0nfUj7O8LO88kTY4u9fULjbIdM9Q1ad399Yusi2sr18 IBMY5hCYHns3I8tJse2WqxR1agdTIjWEjWUzusOdvZXgXZEel5vQiKuprRf9LqUXS5ss pI0Q== X-Gm-Message-State: ABy/qLbrJHLGst0akPyUiJZJ2ZxCvEZElgqqPECR2rFLA/iNlg7o1NEC j997mM5iL2EIJuakfDZlJou9CQ== X-Google-Smtp-Source: APBJJlH9uJ20HU/xu6w4BzlZ8VKOTZ9pA8N8iNM1wVNpNPl9nuSdUi/k4VZmc0YpyQk9a9eYCl1pHA== X-Received: by 2002:aa7:c554:0:b0:522:40dd:74f3 with SMTP id s20-20020aa7c554000000b0052240dd74f3mr9248786edr.39.1690795847077; Mon, 31 Jul 2023 02:30:47 -0700 (PDT) Received: from google.com (64.227.90.34.bc.googleusercontent.com. [34.90.227.64]) by smtp.gmail.com with ESMTPSA id q20-20020aa7da94000000b005228c045515sm5165439eds.14.2023.07.31.02.30.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 31 Jul 2023 02:30:46 -0700 (PDT) Date: Mon, 31 Jul 2023 09:30:43 +0000 From: Quentin Perret To: Sean Christopherson Cc: Paolo Bonzini , Marc Zyngier , Oliver Upton , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , "Matthew Wilcox (Oracle)" , Andrew Morton , Paul Moore , James Morris , "Serge E. Hallyn" , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Chao Peng , Fuad Tabba , Jarkko Sakkinen , Yu Zhang , Vishal Annapurve , Ackerley Tng , Maciej Szmigiero , Vlastimil Babka , David Hildenbrand , Michael Roth , Wang , Liam Merwick , Isaku Yamahata , "Kirill A . Shutemov" Subject: Re: [RFC PATCH v11 06/29] KVM: Introduce KVM_SET_USER_MEMORY_REGION2 Message-ID: References: <20230718234512.1690985-1-seanjc@google.com> <20230718234512.1690985-7-seanjc@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: E48B820026 X-Stat-Signature: 61xbtn3yyxcto6mrh8wccnpw8kssdogt X-Rspam-User: X-HE-Tag: 1690795848-44055 X-HE-Meta: U2FsdGVkX18O75yolfOD1nq7edSO+OhHt6A3+5skKsVPJ0X0yQhNKduTSZsllIzr1jzAekcxi+grdJ7HM4Ml+M0euX3NaI+2jmpkkjLLqvaxqQo33WXYfNYNgI8PBoLlSMZFmJZC0JzuICvV8S3+umse/f5DxyCCSR3ypWafB1f+1ZQrHXXmiZFqmapmjIt1LaYJ6koVaw5aitrjuGsUqDsnjeATrLiQ6cMTkLt2PeuRDw4YFio7EKXBM5HewDzslQ7m8Ck6xwvYeoIcxqesliStwvCm6847Xrb1wTCUwlw+DQDv82wf1jovRjo54Zt/MPXO5sDINVQCWBeCdM5KrYd1DXxmmoup522WZxSEqsGaJW611nNb8Fuqga5YY6gUDF82gnqrjlm2TiZ1KO74fRApmwDtOldWA1Eo4ckH1PQOqSqD27dp1J6OxvPXa6+vtSvf7Qw8cjx2P9n1drr64t1Md1CRQlWbP6++rYsSJTUpPeqojmXtzAQ48JhlbWl98jC3pe4Ue9l9NeiabkLG9hhgcLSMD4lcpt7qzA21iDs6B74PQ++COHTGEvaGTtaZ0aBxS+cAL5Awqy3p0EewUX9J2hiY/vcWzi2+CI+74NetWF0p2INheEtCvvCT3/7Vd4AnCBniTiQGyQLdwM+SYLSsQYQsYnoyFyb5IES4v0mWvqLTu8W36/3ChyGh3dctNwgsBejYq+Sq1ntBobPWzRoXUllRiYvHyfeVWKIhWaVQXu3T2Zr1tbB1vPdXNWpLpSP3ZWrvpbNVrPugU84AiqjuYcNiMQCxL96JiD+u0XEjsAA7U+23NixhopZWn/bExvMvxbZhOQ5SEcMDAi+yGbxWc5hh+EOhhQRKDkF0yTNWa1aGrd9id+ax5WKW7ECnsqbdt2cRWNH4l3QGNapaBmb0jVk3PRwRuy8gRY0HMIVSAPkZYkjceXsbYKxUImLXAPGv+AAbPIM1dTW9cTy SrqIGnfV nyF6qKhVA7HL1cbkMyM7rIoyeXcpjlREuAnXCWyj1cfGYqqMzJIL/EWvi83B4rnHJe6dZRpyrJ64k64QucWhy40E0l1gf5BCJZQxbY4EJm7Ry6FSTqqzku7NB/MhYkxmlyIS0QL877z1IKHvXuvRkAe5NSJTp0oMjFD62kjhkAIDIoi3KKCNPyQOaPLsNfrqp/02wXa9CJzVWSpvUdccLRn/BDAv3C5clOJ8xx8F86UEMUOuUyD1AJor2ZRd2H0nD4xp+0yb7agGb+dOCuQIscilvp8XtQu7qsFJqMMuVeEpL3nshxwG445JXn5ATCXPOAk2U9nZRo2zbXxHTfdETWL3eL/Fzub4AtYkjtaJRjCDwMAVcX0VjMRUzq82gskc1UFBKrvRxHNDYnPm85xaaCvTEEco2b8QmlGe7uDAaKyaxbm+FTXR34xwPVb3XN3UqBk4n4pxWBse3xFxsJ01u9/b29wahnluUg/ahsPksRgDTQ7xjj7Xf1WGrIQv0GLfWkqEuVXpkaBXK3i0zgfZ/428m9B/5ZUdMivkmssd0q0HyBYPnY4LDpHyfJQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Friday 28 Jul 2023 at 17:03:33 (-0700), Sean Christopherson wrote: > On Fri, Jul 28, 2023, Quentin Perret wrote: > > On Tuesday 18 Jul 2023 at 16:44:49 (-0700), Sean Christopherson wrote: > > > --- a/include/uapi/linux/kvm.h > > > +++ b/include/uapi/linux/kvm.h > > > @@ -95,6 +95,16 @@ struct kvm_userspace_memory_region { > > > __u64 userspace_addr; /* start of the userspace allocated memory */ > > > }; > > > > > > +/* for KVM_SET_USER_MEMORY_REGION2 */ > > > +struct kvm_userspace_memory_region2 { > > > + __u32 slot; > > > + __u32 flags; > > > + __u64 guest_phys_addr; > > > + __u64 memory_size; > > > + __u64 userspace_addr; > > > + __u64 pad[16]; > > > > Should we replace that pad[16] with: > > > > __u64 size; > > > > where 'size' is the size of the structure as seen by userspace? This is > > used in other UAPIs (see struct sched_attr for example) and is a bit > > more robust for future extensions (e.g. an 'old' kernel can correctly > > reject a newer version of the struct with additional fields it doesn't > > know about if that makes sense, etc). > > "flags" serves that purpose, i.e. allows userspace to opt-in to having KVM actually > consume what is currently just padding. Sure, I've just grown to dislike static padding of that type -- it ends up being either a waste a space, or is too small, while the 'superior' alternative (having a 'size' member) doesn't cost much and avoids those problems. But no strong opinion really, this struct really shouldn't grow much, so I'm sure that'll be fine in practice. > The padding is there mainly to simplify kernel/KVM code, e.g. the number of bytes > that KVM needs to copy in is static. > > But now that I think more on this, I don't know why we didn't just unconditionally > bump the size of kvm_userspace_memory_region. We tried to play games with unions > and overlays, but that was a mess[*]. > > KVM would need to do multiple uaccess reads, but that's not a big deal. Am I > missing something, or did past us just get too clever and miss the obvious solution? > > [*] https://lkml.kernel.org/r/Y7xrtf9FCuYRYm1q%40google.com Right, so the first uaccess would get_user() the flags, based on that we'd figure out the size of the struct, copy_from_user() what we need, and then sanity check the flags are the same from both reads, or something along those lines? That doesn't sound too complicated to me, and as long as every extension to the struct does come with a new flag I can't immediately see what would go wrong.