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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8EDC9C433EF for ; Sat, 13 Nov 2021 00:53:39 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2A52D60E8F for ; Sat, 13 Nov 2021 00:53:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2A52D60E8F Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 8DD816B0075; Fri, 12 Nov 2021 19:53:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8B2EE6B0078; Fri, 12 Nov 2021 19:53:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A0506B007B; Fri, 12 Nov 2021 19:53:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0158.hostedemail.com [216.40.44.158]) by kanga.kvack.org (Postfix) with ESMTP id 698396B0075 for ; Fri, 12 Nov 2021 19:53:38 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 095E382246 for ; Sat, 13 Nov 2021 00:53:38 +0000 (UTC) X-FDA: 78802084074.26.04E1619 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by imf18.hostedemail.com (Postfix) with ESMTP id 370A7400209D for ; Sat, 13 Nov 2021 00:53:37 +0000 (UTC) Received: by mail-pj1-f51.google.com with SMTP id gf14-20020a17090ac7ce00b001a7a2a0b5c3so8286030pjb.5 for ; Fri, 12 Nov 2021 16:53:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=K0ej+1tfThZ98QHdCkt5YQB5r/oSm3/M9hAu6wXCK3U=; b=pQew5/HXAnO8TXdgTdtaTK36LBnEF12hxJvzN5pABi2kpGIwdP0jSSYCyOaDFbqs6t bwKAugb0mq4C8boLMRoGPo/eficKE+A1dS2ELJ3rbRBCIEoqskUK6pb7xBKsSUaqMuD2 OBdEVbYxwv0wuphazwB+sjYizVyaVYqt+wv/NVYFUAevjGsJC5qS0p6UD0z26mJhPN/w Jfcz6+V2TMsIkfuCPNpshKpBU8GkVMeAaQlGvf/pZhVWc85pyMndF1HZ7gd70OPakshN WrrHW1ILeczlxTQ1xV4SVMUlFtnOKABW6qeH567/akB/5B9ThfR6VIOS8kZgPVxwH0z9 Bcdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=K0ej+1tfThZ98QHdCkt5YQB5r/oSm3/M9hAu6wXCK3U=; b=xbsdSsBiwEKuWrr5e3GOZLpwbEr6MDHTzsOeql0R0q6oU5Jg2eEr1csIjB+1AXRCHu Q/erzKL9jveDhHE3vjdxh4yLlALPwBInQjIlx7hsDpMJJewCmdFFDoubhNCvhIrePY58 CJyW1dIbl1kGwh82+f4Gr6F45HHB9xLvQPVxo3xSquwzO2qG5EA1ab+ImGS1s8TS1AlG 37Uy8hvPZEKk5xSNOaMFQRCvwStTU42Pc59U6XPy71y76GRjxq30fh3OMPPCmbQ5iTVs Fq72Ew13wJROnbthMbBoaOY4Rbwch6ol8ZINRyrc2qkjdbEnKiRH5avKUaRsDLDb2nNg fdWw== X-Gm-Message-State: AOAM533kWYDq5KC4x0g5MBfqGtCd4wMP/pYDi+1Zj4hwLBN6Xf5TVW1v IQGh36kiVrie0RwtB91pjzMlUg== X-Google-Smtp-Source: ABdhPJzvaH9/WtuKy8InOeWLfYciuK7YuNRtWO721BjQxWRj8KMrcbTnMuwbW71a1EwS+pwmgFUfDw== X-Received: by 2002:a17:90a:e005:: with SMTP id u5mr41085100pjy.17.1636764816001; Fri, 12 Nov 2021 16:53:36 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id n7sm7518229pfd.37.2021.11.12.16.53.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Nov 2021 16:53:35 -0800 (PST) Date: Sat, 13 Nov 2021 00:53:31 +0000 From: Sean Christopherson To: Peter Gonda Cc: Marc Orr , Andy Lutomirski , Borislav Petkov , Dave Hansen , Brijesh Singh , the arch/x86 maintainers , Linux Kernel Mailing List , kvm list , linux-coco@lists.linux.dev, linux-mm@kvack.org, Linux Crypto Mailing List , Thomas Gleixner , Ingo Molnar , Joerg Roedel , Tom Lendacky , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Dave Hansen , Sergio Lopez , "Peter Zijlstra (Intel)" , Srinivas Pandruvada , David Rientjes , Dov Murik , Tobin Feldman-Fitzthum , Michael Roth , Vlastimil Babka , "Kirill A . Shutemov" , Andi Kleen , Tony Luck , Sathyanarayanan Kuppuswamy Subject: Re: [PATCH Part2 v5 00/45] Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support Message-ID: References: <061ccd49-3b9f-d603-bafd-61a067c3f6fa@intel.com> <2cb3217b-8af5-4349-b59f-ca4a3703a01a@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="pQew5/HX"; spf=pass (imf18.hostedemail.com: domain of seanjc@google.com designates 209.85.216.51 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 370A7400209D X-Stat-Signature: a48ozeze5pz1rqq8oiktnjpwo1t9iy8m X-HE-Tag: 1636764817-233038 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, Nov 12, 2021, Peter Gonda wrote: > On Fri, Nov 12, 2021 at 2:43 PM Marc Orr wrote: > > > > On Fri, Nov 12, 2021 at 1:39 PM Andy Lutomirski wrote: > > > Let's consider a very very similar scenario: consider a guest driver > > > setting up a 1 GB DMA buffer. The virtual device, implemented as host > > > process, needs to (1) map (and thus lock *or* be prepared for faults) in > > > 1GB / 4k pages of guest memory (so they're not *freed* while the DMA > > > write is taking place), (2) write the buffer, and (3) unlock all the > > > pages. Or it can lock them at setup time and keep them locked for a long > > > time if that's appropriate. > > > > > > Sure, the locking is expensive, but it's nonnegotiable. The RMP issue is > > > just a special case of the more general issue that the host MUST NOT > > > ACCESS GUEST MEMORY AFTER IT'S FREED. > > > > Good point. > > Thanks for the responses Andy. > > Having a way for userspace to lock pages as shared was an idea I just > proposed the simplest solution to start the conversation. Assuming you meant that to read: Having a way for userspace to lock pages as shared is an alternative idea; I just proposed the simplest solution to start the conversation. The unmapping[*] guest private memory proposal is essentially that, a way for userspace to "lock" the state of a page by requiring all conversions to be initiated by userspace and by providing APIs to associate a pfn 1:1 with a KVM instance, i.e. lock a pfn to a guest. Andy's DMA example brings up a very good point though. If the shared and private variants of a given GPA are _not_ required to point at a single PFN, which is the case in the current unmapping proposal, userspace doesn't need to do any additional juggling to track guest conversions across multiple processes. Any process that's accessing guest (shared!) memory simply does its locking as normal, which as Andy pointed out, is needed for correctness today. If the guest requests a conversion from shared=>private without first ensuring the gfn is unused (by a host "device"), the host will side will continue accessing the old, shared memory, which it locked, while the guest will be doing who knows what. And if the guest provides a GPA that isn't mapped shared in the VMM's address space, it's conceptually no different than if the guest provided a completely bogus GPA, which again needs to be handled today. In other words, if done properly, differentiating private from shared shouldn't be a heavy lift for host userspace. [*] Actually unmapping memory may not be strictly necessary for SNP because a #PF(RMP) is likely just as good as a #PF(!PRESENT) when both are treated as fatal, but the rest of the proposal that allows KVM to understand the stage of a page and exit to userspace accordingly applies.