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 5A4C3C7EE26 for ; Fri, 19 May 2023 19:57:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 98160900007; Fri, 19 May 2023 15:57:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 93139900003; Fri, 19 May 2023 15:57:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 82085900007; Fri, 19 May 2023 15:57:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 73499900003 for ; Fri, 19 May 2023 15:57:33 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 38722120B2D for ; Fri, 19 May 2023 19:57:33 +0000 (UTC) X-FDA: 80808064386.25.8A23898 Received: from mail-yw1-f202.google.com (mail-yw1-f202.google.com [209.85.128.202]) by imf02.hostedemail.com (Postfix) with ESMTP id 754748000D for ; Fri, 19 May 2023 19:57:31 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b="Y4/nCNzr"; spf=pass (imf02.hostedemail.com: domain of 3qtRnZAYKCB0L73GC59HH9E7.5HFEBGNQ-FFDO35D.HK9@flex--seanjc.bounces.google.com designates 209.85.128.202 as permitted sender) smtp.mailfrom=3qtRnZAYKCB0L73GC59HH9E7.5HFEBGNQ-FFDO35D.HK9@flex--seanjc.bounces.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=1684526251; 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=pKqky4qtLhLMqwc+jYDJn6p8bYat7L/lp+nKxMPkRyY=; b=cO7YvzNYgiDldLWwP3kPmBqmkcyjONevzQoVZlEcxxq+ooIzJgcuiznTJyDZv1gbkMJM3s Mua+YmtdHe6BUs+E+OaGSxdAMDxC+mte/20ZbcHHb4LwHAE5DaV6ekXkYjmznTZQKIxTtd FOv0qH8xqR9rxxk94xgRTeFqpLrHxCA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684526251; a=rsa-sha256; cv=none; b=dGkMiq8jEsk8SFducsQgIE6wtueV5+dwbrWvcnK/DRHYPK0rbXGj7Rtt+L/3rjz0omyGna cVX5Y/wjbjvEeSqZkqE9YLw40vXcQqg9Y1J3EdjaWre2f/6Epc15z43dr7FPanUnEjT2zL Kf24xrJSTztAsTtUBTW2MNEOEb3+Re0= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b="Y4/nCNzr"; spf=pass (imf02.hostedemail.com: domain of 3qtRnZAYKCB0L73GC59HH9E7.5HFEBGNQ-FFDO35D.HK9@flex--seanjc.bounces.google.com designates 209.85.128.202 as permitted sender) smtp.mailfrom=3qtRnZAYKCB0L73GC59HH9E7.5HFEBGNQ-FFDO35D.HK9@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yw1-f202.google.com with SMTP id 00721157ae682-561ceb5b584so66641477b3.3 for ; Fri, 19 May 2023 12:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1684526250; x=1687118250; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=pKqky4qtLhLMqwc+jYDJn6p8bYat7L/lp+nKxMPkRyY=; b=Y4/nCNzrFtAXrTxhpgxnIohVGQ15GL4scvI0E/2mwJYj0GQbPVuXot7Jeu/0WvRvj2 9Uxos5w5dD8ChOUGochlppnIBC5WV72wtD3Z57q1qVzEB6BAU0zrp0Rj839OpxiYl1kv G7aILpvUERbXB4ndb2rR/5sC8oXuhx9NqV1vUAEDqYGF4xFHckOEfCC8e/Xg4DdMuR9l zQm9PUkP+OBFNpwTjL8yMr9HKgLvxTY4wkwyU4C1eKD22zw0o+8bYInRVaF8kFuyTWom 12s22nrLwFtLZKHZJekTC38ZFlIu/iG4U6Mf6VoeQ952/z/sfp8161qhLkUY71jT5lqI iHcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684526250; x=1687118250; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=pKqky4qtLhLMqwc+jYDJn6p8bYat7L/lp+nKxMPkRyY=; b=Y+wRI15XPF8/9NKGmyIluCNgzrSRMDK5iRwxL/Hp8PoD6laa3qMHDoe3GCLsdT8WBt NN593goehDyb/2GjVAV4G6f1/MlqARuyTen3VW+NY4B7onjkwJfGDFHJK5q22C2o4rA1 8aPTVMavXMSytRkeGK9uIc3dSdiS45WOcf0DxXZSDUJX4AnSF+Az5dLnpmIlepTS1DFC 0yDwwfvAq7MpuqIS5tkxqenmK+HiqWTuy40S0yRcOS778yo18n5fZabVFLOexptc5jrb C9gle0OR6ySG7Dy8Xt37gTx56bkyd/Wxr4SUKM2C8i+wULUXd4PgT4NKe6qLPw6UAy7h Ht9g== X-Gm-Message-State: AC+VfDwEiaGyEqRNDtg4l+wHVTkFEYvol1GQKWgWONWt/pnsjPT/qnNQ 3l1mKTb+ejrHfbFM0O6px/6Z4PVSDmc= X-Google-Smtp-Source: ACHHUZ6FEiPmU5v43LWifQRBpo81052L49sw5QgxYInZToAzWsR8mGtYDH7+PppQKkPgp34+c6aLJuvLWhk= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a81:9f0a:0:b0:561:949f:227 with SMTP id s10-20020a819f0a000000b00561949f0227mr1854093ywn.1.1684526250423; Fri, 19 May 2023 12:57:30 -0700 (PDT) Date: Fri, 19 May 2023 12:57:28 -0700 In-Reply-To: Mime-Version: 1.0 References: <20221202061347.1070246-1-chao.p.peng@linux.intel.com> <20221202061347.1070246-3-chao.p.peng@linux.intel.com> Message-ID: Subject: Re: [PATCH v10 2/9] KVM: Introduce per-page memory attributes From: Sean Christopherson To: Nicolas Saenz Julienne Cc: Chao Peng , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, qemu-devel@nongnu.org, graf@amazon.com, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Arnd Bergmann , Naoya Horiguchi , Miaohe Lin , x86@kernel.org, "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Shuah Khan , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , "Kirill A . Shutemov" , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, david@redhat.com, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , tabba@google.com, Michael Roth , mhocko@suse.com, wei.w.wang@intel.com, anelkz@amazon.de Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: 754748000D X-Rspam-User: X-Stat-Signature: o5uqi5xwsttjr5bzef55j8kq16pudrna X-Rspamd-Server: rspam03 X-HE-Tag: 1684526251-489431 X-HE-Meta: U2FsdGVkX1+vBrvTHi6kjkQrtILOPks7va5xb+1K4HJbJbwutK1wgQ1cy9q9U1F6MYc1HVxElTpYg9XTr3g3wGCngSaedKY3cGVso/Q5Z3LccBFPHrIHylr0WGQ0czAtgHxYNbKFEZe7RLqK/ACjYsFdBs3T5vVdBCVH0pz9q9e/JUipy7zwxaQwzAFCTKStr1AEdt6DLIjxHrhFcYuPVzaWJHjssuPRvrH5JrSdMJoMZ06UnSuf/QgFQONnh9rFqv93yWhPYp7b5SR1v+gxxoq10Dtp7F6U9w+a2FCcm2E2pSPmFNcrSz9ZYZyyCqZxSsCUTlvEWwoWP3kQ0jvhDPm62tdumIY3A6ynioG1/yrDl6e0VdqDWpiLVdD8NNhxIymu8Ds+WVu/lSp3nfbsxAvx6vyzQi5tjAETOyiMcsBsak5g0zEM1MmhSDvmD87E+Bc3qFiDqrs+L54VlYsj7QBueNvpxl5i5VBLOnOpy0X9dLvHpqZvnvULsyQEOj/+zSMB7w83AnVBM6tUCzdo+tyeIIyMBwK1OBx7ARMfKIkyH/V6jf1mki6ZRVC6BzgG7X7XyGYFLb/B3SYomkzdKZSvOyx5e2vPXPUjzHEqbNJXXfFjUJ0OAXnIWIwF9B+j49KceCKHsBMvffJUHlP2R8sfm/9D2TEFx5CeNQGYatV4jwA1gkcdzZ5jXFXZgk2VS2P2BnOuMQXeyEtSrPnnmowkvqTVG3KiLSbpVYSQiWw8bd1IRDxWyMyO4di+4NVMIftru6kUWYjDUHB1kS0Oa7ETVV4R3FZEOHDgUIGYmAUPHhPZwl1Ck9GdV5+gSR0Kk7P0vfGOeyBhjfGkp0JJtkA1tBd7VOofFScdXgmQ829KXoL+ISB7ANgM3km7cEBFQAOe9DdpRxYTTvUwI2L23E/zUWI5MVgVoLiow6Kky7AZSz3+lDi1jcLtkzS+M4dM7WoAi72XmbZZoNuY1t1 Ws5Vy7DU jJ7jVq3+lbSl9EmpQgLHBGWwBohxXHH0YurdLr9TLw0mmm5s7lYh0NV4JiQbqLmzwJzKI4MGxckn6klU31ifgMbEN/BnuDvXkPpPawzj59HCU34VRgEQ9TvgxgmlWTLKqb0QNjFoYlBebv/lT86u6kKtJaEuvrgZvJWVerI6EgBFpIdfL4vuqFCktCNTfHFInFnv3fiHycvx0SX5xBVX6Lj7yVinPSNEm6f0D+Ghp9Lrq87OMQYxSawyTtyRQdGd+0emwMG2AOyTK6YcrAb1uDnuhOdCdbQl+S0MFPhOj0V5RcDUpIwrqcyxo9T+Pb/JkLKXBUHsLpcP+oJqkgMnTDeARtAmNtcrzSr/Vz4yt8hKVIZBjiRPLSHOt7p0pASDuC4ndgTGIZum07NC1C+R+Wb1hmyiEtSnM0KF4cABVf2E4ZuV+H1Oo4INOovVRkuTIOpLHIfV23Dvr4Tl+s/dsmAc5QvhuEOS5dMUxMmMs99tNzeyQKBbrDH2RLfhEZh+ybuB1zmw8DgmcakPVKWbiVQ1r4F4iWN82g/fUiomrGLJSHNPorEj20F5/IDZM74VomquED9J3M9kCIbxRen8u5ZGUIA== 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 Fri, May 19, 2023, Nicolas Saenz Julienne wrote: > Hi Sean, > > On Fri May 19, 2023 at 6:23 PM UTC, Sean Christopherson wrote: > > On Fri, May 19, 2023, Nicolas Saenz Julienne wrote: > > > Hi, > > > > > > On Fri Dec 2, 2022 at 6:13 AM UTC, Chao Peng wrote: > > > > > > [...] > > > > +The user sets the per-page memory attributes to a guest memory range indicated > > > > +by address/size, and in return KVM adjusts address and size to reflect the > > > > +actual pages of the memory range have been successfully set to the attributes. > > > > +If the call returns 0, "address" is updated to the last successful address + 1 > > > > +and "size" is updated to the remaining address size that has not been set > > > > +successfully. The user should check the return value as well as the size to > > > > +decide if the operation succeeded for the whole range or not. The user may want > > > > +to retry the operation with the returned address/size if the previous range was > > > > +partially successful. > > > > + > > > > +Both address and size should be page aligned and the supported attributes can be > > > > +retrieved with KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES. > > > > + > > > > +The "flags" field may be used for future extensions and should be set to 0s. > > > > > > We have been looking into adding support for the Hyper-V VSM extensions > > > which Windows uses to implement Credential Guard. This interface seems > > > like a good fit for one of its underlying features. I just wanted to > > > share a bit about it, and see if we can expand it to fit this use-case. > > > Note that this was already briefly discussed between Sean and Alex some > > > time ago[1]. > > > > > > VSM introduces isolated guest execution contexts called Virtual Trust > > > Levels (VTL) [2]. Each VTL has its own memory access protections, > > > virtual processors states, interrupt controllers and overlay pages. VTLs > > > are hierarchical and might enforce memory protections on less privileged > > > VTLs. Memory protections are enforced on a per-GPA granularity. > > > > > > The list of possible protections is: > > > - No access -- This needs a new memory attribute, I think. > > > > No, if KVM provides three bits for READ, WRITE, and EXECUTE, then userspace can > > get all the possible combinations. E.g. this is RWX=000b > > That's not what the current implementation does, when attributes is > equal 0 it clears the entries from the xarray: > > static int kvm_vm_ioctl_set_mem_attributes(struct kvm *kvm, > struct kvm_memory_attributes *attrs) > { > > entry = attrs->attributes ? xa_mk_value(attrs->attributes) : NULL; > [...] > for (i = start; i < end; i++) > if (xa_err(xa_store(&kvm->mem_attr_array, i, entry, > GFP_KERNEL_ACCOUNT))) > break; > } > > >From Documentation/core-api/xarray.rst: > > "There is no difference between an entry that has never > been stored to, one that has been erased and one that has most recently > had ``NULL`` stored to it." > > The way I understood the series, there needs to be a differentiation > between no attributes (regular page fault) and no-access. Ah, I see what you're saying. There are multiple ways to solve things without a "no access" flag while still maintaining an empty xarray for the default case. E.g. invert the flags to be DENY flags[*], have an internal-only "entry valid" flag, etc. [*] I vaguely recall suggesting a "deny" approach somewhere, but I may just be making things up to make it look like I thought deeply about this ;-)