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 A0D20C77B7A for ; Fri, 19 May 2023 18:23:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BF161900004; Fri, 19 May 2023 14:23:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BA13A900003; Fri, 19 May 2023 14:23:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A9065900004; Fri, 19 May 2023 14:23:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 9A8BF900003 for ; Fri, 19 May 2023 14:23:28 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 72D22A0B34 for ; Fri, 19 May 2023 18:23:28 +0000 (UTC) X-FDA: 80807827296.25.36F57A4 Received: from mail-pf1-f201.google.com (mail-pf1-f201.google.com [209.85.210.201]) by imf30.hostedemail.com (Postfix) with ESMTP id B538380011 for ; Fri, 19 May 2023 18:23:25 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=ITz9fDEY; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf30.hostedemail.com: domain of 3nL5nZAYKCOEVHDQMFJRRJOH.FRPOLQXa-PPNYDFN.RUJ@flex--seanjc.bounces.google.com designates 209.85.210.201 as permitted sender) smtp.mailfrom=3nL5nZAYKCOEVHDQMFJRRJOH.FRPOLQXa-PPNYDFN.RUJ@flex--seanjc.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684520605; 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=DLB02Z/Vwsol/Ye6PM6jgDdfosuGHdGXe49pn4jVFGs=; b=lk670dY8vgvl/e+W7kuO132d0qvEmGPD/uqXBdGrzJjC1Jw+BK7l9Q07B0S9ADxjilMt9z mbliU9dbRDCWBj0vAe+piIRQFWAJjQXcgUH/IIOKe73Xy9n77mBcP7dxu3hdeXKusSjsod hwmWBniSquDJOSGWmn5Tu++6lb84ynE= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=ITz9fDEY; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf30.hostedemail.com: domain of 3nL5nZAYKCOEVHDQMFJRRJOH.FRPOLQXa-PPNYDFN.RUJ@flex--seanjc.bounces.google.com designates 209.85.210.201 as permitted sender) smtp.mailfrom=3nL5nZAYKCOEVHDQMFJRRJOH.FRPOLQXa-PPNYDFN.RUJ@flex--seanjc.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684520605; a=rsa-sha256; cv=none; b=S1SkcdN6L1B33DksVst3l1eYHzBn8OHL62mdzNsIrtQu3qrPFiA3nrZ4rfBggvI3obUC9x ST4aR9d8fhLOMsyKD1CnLVQBU1RHJGZijqk3VdlLLflrIws6PObmmgw+I73kQDK0VKmPuk XPP+OmMSr4D5JLw/zv357+DAAgpMdEc= Received: by mail-pf1-f201.google.com with SMTP id d2e1a72fcca58-64d1c53cad8so2538436b3a.3 for ; Fri, 19 May 2023 11:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1684520604; x=1687112604; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=DLB02Z/Vwsol/Ye6PM6jgDdfosuGHdGXe49pn4jVFGs=; b=ITz9fDEYRz6uJ1+nRWO7vsSi14em+HdSJidcWgxJ4Wt6DeOJu7xDarNLoGHPPmOBJm 513df8JS3NzUdZBK5GSwxSAE1obesd28XWXoOz2iBbvdy2ADgD8Q7q4etCMKIPinEZf9 82KenOrwjvv/KK8vs+qKxwowe4qePsP8+TuW1ty9rOYtzfzi/ynfD476K7Sa4jcxQ34p HkwfUr8RcwOMfxti367AckaqXDd3aDIN65dnmKhBIIZmfTcWPib/CZQFAhBLIgn2eTM2 VcgA71nqkKuEZwM79FEKmyy8iW+KFC3fLH2DABkTHNX+7IlmO+RnTTQJhuLLoZh1rgpR H95A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684520604; x=1687112604; 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=DLB02Z/Vwsol/Ye6PM6jgDdfosuGHdGXe49pn4jVFGs=; b=VLN0hHnusCiNxQQKtyEmEiY2KjdERlyr+B42T8rPn0EztvcXduqe08EjmBJoXl6+3/ USsNM+AeLxP/3xWj10cPrYvZx835IYKVIkGiitasA/nYAPAjWQHWz/PJXeFeX2DSsSwQ 73AvKlPemzVoVTrh9S74qSqfGVdDUXL3UAj9cj5Hc6mEuikPWTyRlP/51oK2FzQkpCRH kd/9QxNmO+RS2kf8fI1KzMHzR3rGPDKKGtDo0utGYVv3t3txI4kac/2EYg7cpAoGOz8B Q2pUBCocxjZjfGW6izlS+pZ857VLYLmDP0T46mRaNwmeynH1C5rUzoW8SfkO4AVUencU 48tg== X-Gm-Message-State: AC+VfDwRM0Kqza2aQM79SCYjy/6DiFBmw5837NwATZTrskDaF8bm3NTQ lUbBICbk9ImfHZsuA0waKjKmNH5+FLM= X-Google-Smtp-Source: ACHHUZ419BZyva9XfjdHZezzlVRJTJng9P1rwHIVB2iZ3Kvn5yX6WZYPLwlGGRjyBM2xKvPRPQpWmzT2ch0= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:aa7:88c4:0:b0:643:4595:64c7 with SMTP id k4-20020aa788c4000000b00643459564c7mr1352262pff.4.1684520604384; Fri, 19 May 2023 11:23:24 -0700 (PDT) Date: Fri, 19 May 2023 11:23:23 -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: B538380011 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 3apgk98wunst1uuoamnwoetdhquisz4i X-HE-Tag: 1684520605-28531 X-HE-Meta: U2FsdGVkX1/pEToUzfHygo9dgLr3jtFBlpTElMuMyjHopDXRByM85RpaG+B/+t1gqgM+UZdvuQ1wPX9zNO9teP0me+vR3aoSrn4pgmLS+QzGuG2q6j4Y3YiJSFziJ+tzPj5HOySDgmVtBhkxRdLx9MWA7E8XZQ96pjbj7tZAwGEZalwG0bgNExlSnYoUOhx7xqNiMfk/oTekyeDZqJ6j8bIr7QnIn+j8phjIhXP/TwhTAHnOH92zT20PBAZnpb02ZFKFPPet13chsW+HryWLPqsbljKsY/FxVrQ31cAe5RCjhALU5u0zh6VdwTsncilqXaOzuH1Ab344wy6dQ6eu2E7ZpoUjaxEf82ssruiJqziGQfeM51C1vflOiYuVv3y3u3m3wznj44pUNnhc2F1n4awXItNl9fAPOgwte/F+C83+ZQL+W2e41ss79tu8N8IxuN9JEi9KPIB5euYPeKQ1ifrGAwpR/1SlgJRlRW7ueeh85vSRJSWPS8YmR4Yhxnci1LSTQxjaVkuYmv5LLf9FSvusqLC+DzFAA1YG63aROtrjT2LNY4lR0QsJjOknrNPrlnieTAtSlBGlSmmINnjf/rgT1Cl8B8ZWPArT1O/ib16hYA2PKI5+OiunmsoZvhmcIWb/jURAOyiW3K+g5Xr2fF/F/AmT2aF9aRbUhsPxOjvHrBi3aIcUXMeXdi4Hs5lqRtavbPr0BMOeZPo+U+xc0LFc9l9ceD4vwcAUMkP3JpBP1lLnwG3IIIFtYMIgkazncTI4wD9WPXQLyogTQreJ4n8HAvzumsGdZxU11EQ4lYWeNejn8EVX9Vo/mETTRs9OL7HF+vGlnEnpuLbrD8oO9emO371KReBAOHgRn4oyGGt98NLDSLasWFU01y7nIt1Qp/P4e87tZrt4Ep1pS6V1TVWrkS7R8tFed/Pw1xsdu9JAO6TMmqqUbK0lzdrpnI4enuyV1Zpqv06Ne8sXGkh UWQZlhMh JkRetkb0Z6EW7Zkk4I7nZNqsuLIY4K0YqHV8QDkHzs8VVssY3ZVgZHMXqmZDMY8+MNfKgmiE6mBmfKif1WJzGoXWjmmC6TEXs2SxvxJ5EK+7l7UfUagRxmpJ12S5RBAmT5e9K3JQ5vejl/ziIpuJtDRWHda0G+WIwtxCbp+zY51uPmCqifxWrCCZlr2M/eg23/66ZQeNts6yeLYNgomewkMjm8vh35Jq/jyyYwvWn7LWnEb3LzrytZhc4moNcbrAGw75VNEZxpRJKV6AWYHXu7ufXhhAi/k0Cr+C0VRCpfeRiZYHMj+66lQIJyGQoLI/T6nWtLN5DjAqeYZ7fDuMKZO/6DQTYhpkA0O5pLqrAkZtIMdkwo3iwXSliVtQUmfDUaVuPYghQfWt428jRKlcO3vpODZrPbaksZj/72IyeKQLj7jDfCDEs1gLp7zXT/MXD8QxbDMKR1knOAj7P9vSvc95GYcI0A2M0/mvUGB8/RDNxavI5SmpcVrNZ3MxanI7dSylJ1VjMU4R2R9yFIHTFy8gMtYW2/YpL0JOH2T+7fZVcqTl8iW09stv3jZwouyGfksI/F5Jhl5ipsv7fMsa/SiDvpz321AGZwwZ64mepB2Od5zwXnHgAhUPBX/ae38yLcijdJ5ZuNWoXnfL/mwq+OlFncfkCO7EtquwP1m1+I6rBvVWycIDrOK2XKXHmY6Q7P5hxP3jxb9IZ/IM= 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, > > 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 > - Read-only, no execute RWX=100b (using my completely arbitrary ordering of RWX bits :-) ) > - Read-only, execute RWX=101b > - Read/write, no execute RWX=110b > - Read/write, execute RWX=111b > 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 means SMM, but the VTL comment above makes me think you're talking about something entirely different. E.g. can you provide a brief summary of the requirements/expectations? > Also sorry for not posting our VSM patches. They are not ready for > upstream review yet, but we're working on it. > > Nicolas > > [1] https://patchwork.kernel.org/comment/25054908/ > [2] See Chapter 15 of Microsoft's 'Hypervisor Top Level Functional Specification': > https://raw.githubusercontent.com/MicrosoftDocs/Virtualization-Documentation/main/tlfs/Hypervisor%20Top%20Level%20Functional%20Specification%20v6.0b.pdf