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 B29ACC7EE26 for ; Fri, 19 May 2023 19:49:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E8D33900005; Fri, 19 May 2023 15:49:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E3D0D900003; Fri, 19 May 2023 15:49:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D2C91900005; Fri, 19 May 2023 15:49:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id C400C900003 for ; Fri, 19 May 2023 15:49:49 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 8E0DB140A93 for ; Fri, 19 May 2023 19:49:49 +0000 (UTC) X-FDA: 80808044898.16.106447A Received: from smtp-fw-80009.amazon.com (smtp-fw-80009.amazon.com [99.78.197.220]) by imf11.hostedemail.com (Postfix) with ESMTP id 74D9240012 for ; Fri, 19 May 2023 19:49:47 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=amazon.com header.s=amazon201209 header.b=aZ5gzVkv; spf=pass (imf11.hostedemail.com: domain of "prvs=496baf2b8=nsaenz@amazon.es" designates 99.78.197.220 as permitted sender) smtp.mailfrom="prvs=496baf2b8=nsaenz@amazon.es"; dmarc=pass (policy=quarantine) header.from=amazon.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684525787; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=W0aeDSQlpa8RnbtI8R4fU5iLyJqG7lFtVnkckklLVdU=; b=I7W+K2jD6DviQtrLUDEhFoii2hhzOt7B4ORY17PkUlFazTZoTPlbsF4Y4Cs62pItavaOJa qdHQkkmHStrDNdI0RXBxenQ+nVtXqVJp5YiWtnkh0AVxvUxgtkhNmiq74Poj8nM8z7WJms llBSuKyr1tdTsSC+2vkaqsfAGBVwAFA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684525787; a=rsa-sha256; cv=none; b=La0dt3jlMPEDajayrEpEbnydq3OllEtEKxXdxw/kxVi5T/g0dfxG5R6UwDCip5v5+OHbi9 7+qKBPdK6o//5IUJv7VUeJq20wW+x4vDnGtlmVcGU2dNlwOLdOFHH1Jehuc3i0941zZOC0 /KN5cLJjeXalUX5ICKThEfHw5S6umrs= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=amazon.com header.s=amazon201209 header.b=aZ5gzVkv; spf=pass (imf11.hostedemail.com: domain of "prvs=496baf2b8=nsaenz@amazon.es" designates 99.78.197.220 as permitted sender) smtp.mailfrom="prvs=496baf2b8=nsaenz@amazon.es"; dmarc=pass (policy=quarantine) header.from=amazon.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1684525787; x=1716061787; h=mime-version:content-transfer-encoding:date:to:cc:from: message-id:references:in-reply-to:subject; bh=W0aeDSQlpa8RnbtI8R4fU5iLyJqG7lFtVnkckklLVdU=; b=aZ5gzVkv8a1VScNd838+BaeltuqVwunXS2qDxhxQ4OjTOFWSfX4ziIdY uiagGHywV8QoY9R809utpK3rHpIis32F2WyBEP3TirjkIT/b6UyjCEAm3 svyE016/srsOwSecLeQJtvUX0fFwvvyuIQ0Amq4gD+d43abh7pWmUVWLa 0=; X-IronPort-AV: E=Sophos;i="6.00,177,1681171200"; d="scan'208";a="4376891" Subject: Re: [PATCH v10 2/9] KVM: Introduce per-page memory attributes Received: from pdx4-co-svc-p1-lb2-vlan3.amazon.com (HELO email-inbound-relay-pdx-2c-m6i4x-e7094f15.us-west-2.amazon.com) ([10.25.36.214]) by smtp-border-fw-80009.pdx80.corp.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 May 2023 19:49:44 +0000 Received: from EX19D004EUC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan2.pdx.amazon.com [10.236.137.194]) by email-inbound-relay-pdx-2c-m6i4x-e7094f15.us-west-2.amazon.com (Postfix) with ESMTPS id 9CE90410CD; Fri, 19 May 2023 19:49:41 +0000 (UTC) Received: from localhost (10.13.235.138) by EX19D004EUC001.ant.amazon.com (10.252.51.190) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.26; Fri, 19 May 2023 19:49:27 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Date: Fri, 19 May 2023 19:49:23 +0000 To: Sean Christopherson CC: Chao Peng , , , , , , , , , , Paolo Bonzini , Jonathan Corbet , "Vitaly Kuznetsov" , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Arnd Bergmann , "Naoya Horiguchi" , Miaohe Lin , , "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" , , , , , , , , , Quentin Perret , , Michael Roth , , , From: Nicolas Saenz Julienne Message-ID: X-Mailer: aerc 0.15.2-21-g30c1a30168df-dirty References: <20221202061347.1070246-1-chao.p.peng@linux.intel.com> <20221202061347.1070246-3-chao.p.peng@linux.intel.com> In-Reply-To: X-Originating-IP: [10.13.235.138] X-ClientProxiedBy: EX19D032UWB002.ant.amazon.com (10.13.139.190) To EX19D004EUC001.ant.amazon.com (10.252.51.190) X-Stat-Signature: bs636pd6gk5jbryhxbteiaj8157mtw93 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 74D9240012 X-Rspam-User: X-HE-Bulk: true X-HE-Tag: 1684525787-610406 X-HE-Meta: U2FsdGVkX1+Sr4epovlbIMewQb22eunWPVERBmWqB/ZLSDfzmLL3DmZKdVdTSoqqzH3ISZAZRZhHUZgOicQ2nOOic74kRKWrYTaBg+c7aA6VtiyLgiSmTYUHRc+zm3irbXK0H+ei3mPx0b1qLgxj9c4ISC1YBL2VgWroz0s+II4Mb5rpM8WTwmJCVW7bZUqN7bb6kqf88CEr/Gj3ne24RoZzchF1h6xzyavVN0lDHqHiIm9iAjJie6TDXCTsQlpDPFCTXLHGzvueFJqY7jqlPwBGV2vwLit6zKMQYQvRGYBJfuSU2Ft0EgYflARoMsEhkz4uGTQabJPa9ceGu0a/fUKq+5vX+aobXr8VB9I8kJfsb/IzXkaFALM3zbTrKjisO/AOnyqE6I9/Qo1HR521WXijxFiJSB4S9jZw1l/kavtLuBC92pxA0/9D0wG1uLqLaXOUpQHZWwF3ybaoD/0TV+UKgvK6tcp+NGWym3gATRORIjZi5ELjTYgdA2Ih++e+HCnxn2hkeUnFmeF04mqvDGZjo1P5OZhMZY+tw/07orSm+X6sU2gei7S0SvP0kwmy0q/4wHLCYoWQKBsFlgzxu8eXZc4qcXLrxNeqa40tPuUPTmIW7xanx741ayO4AhkYYouQU9cCGqUlKLrjy9pFz4Dx0KHg8Vr1jlEtS1i/dHR50vEk4dfnkMDBUSgK4D+hspSBO7TsZhAe+gsjgO//V/7OhYg5fEPTxFPsMjvoN0flIm5qxT1NnZgvvzTTcWALXC8DkfKDg91JruH15GsTaIHMr6YISxauZnqV3E9Pj58+tyCOde5gW/8NPtO9HCMvvsXNhzaZZ+obbpnToFQjoP2L9eQkowu2GFTvqwbPxbdxa0G+HusJscbc/gwhHynDjYWlVpcHHYmd9OFa+f1QlXO4nQQioggFgR88tUiLAFhPILVVFpcvL/rGlZNxiVje09mTgWvT+ViOk4VHESj 2SBvwFa9 Z6ADAD4xUiga21XOwnWC5+EKSNNMVYpVAMVkuwRDc+YEzA29ITzfV5eUjLH0y23bNemblUimy0Nh3yyyPjo8vm+6febRZA9oeqjlgkFjRJ/TDgZcG7qk+cYqBzsWEV+3loRXuR0bDwQXXhrZxD3Ie320G2tJ49B2RnQTkedoWSR6YIHkvoC9wj1vsnNPpyReiDb3vPHExkT+X+2wlbREqWvPNw2HfCd+rDPc4xfZrsqMlCLVn7cHCB/eNpXfrk41/9SUQPSNBG1fAr8jY/FpLUJqpTj6I2uSe0oCxCzyf2N2NLRyCqqLUqy163Cb67i7YK4I2ECEh1VM0+JHjvZiSyikzaVotXGGdufTBinea+g0107FzZaf8J3MeBrU56qXfw9EDUDziO1o5B0z+ACz3O+xBdSDhhdQzDiemLkA7KLpUJNY3JLqHGkjWogXl99Q9Vjgr+T+a1jvgZm+EFIzsMOqkwtDYlHPiVvVl583DujDC3pBbcQlO7sGjS8EhlOV4NP1ObQzeNJxqnzw7tszarwIxLP4I3hduNpU89SzYX/5HFjFtkO3VR6niJ1ZkMnPs2oq2mhdZIfgZaps= 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: 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 refle= ct the > > > +actual pages of the memory range have been successfully set to the a= ttributes. > > > +If the call returns 0, "address" is updated to the last successful a= ddress + 1 > > > +and "size" is updated to the remaining address size that has not bee= n 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 us= er may want > > > +to retry the operation with the returned address/size if the previou= s range was > > > +partially successful. > > > + > > > +Both address and size should be page aligned and the supported attri= butes can be > > > +retrieved with KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES. > > > + > > > +The "flags" field may be used for future extensions and should be se= t 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. VTL= s > > are hierarchical and might enforce memory protections on less privilege= d > > 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 userspa= ce can > get all the possible combinations. E.g. this is RWX=3D000b 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 =3D attrs->attributes ? xa_mk_value(attrs->attributes) : NULL; [...] for (i =3D 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. > > We implemented this in the past by using a separate address space per > > VTL and updating memory regions on protection changes. But having to > > update the memory slot layout for every permission change scales poorly= , > > especially as we have to perform 100.000s of these operations at boot > > (see [1] for a little more context). > > > > I believe the biggest barrier for us to use memory attributes is not > > having the ability to target specific address spaces, or to the very > > least having some mechanism to maintain multiple independent layers of > > attributes. > > Can you elaborate on "specific address spaces"? In KVM, that usually mea= ns SMM, > but the VTL comment above makes me think you're talking about something e= ntirely > different. E.g. can you provide a brief summary of the requirements/expe= ctations? I'll do so with a clear head on Monday. :) Thanks! Nicolas