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 36553ECAAD3 for ; Wed, 14 Sep 2022 08:05:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A73386B0071; Wed, 14 Sep 2022 04:05:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9FACA6B0073; Wed, 14 Sep 2022 04:05:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 84E768D0001; Wed, 14 Sep 2022 04:05:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 713916B0071 for ; Wed, 14 Sep 2022 04:05:55 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 4D1FCA94CC for ; Wed, 14 Sep 2022 08:05:55 +0000 (UTC) X-FDA: 79909957470.29.BEBD951 Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com [209.85.216.45]) by imf11.hostedemail.com (Postfix) with ESMTP id 1483F4008F for ; Wed, 14 Sep 2022 08:05:54 +0000 (UTC) Received: by mail-pj1-f45.google.com with SMTP id n23-20020a17090a091700b00202a51cc78bso11869288pjn.2 for ; Wed, 14 Sep 2022 01:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=BqUhxcUOvv8EZWeVoadoEfAKAvxiKy4DFaV8F/F3nRo=; b=Y45pldWaU7msnCMC3mB1XfdqYiXenh8aXHlb6P8wpifZtyvVUiC/Pmw9QwKSxvKaE1 5vCUZeWVnXL53VuRrWpqC7y1PQSe7vOrfidrlH914Nd9vnCG1aZejYGhPNdsgrnD5Smm /VxtyFzzPQwbhCVzigMHS4tQiLksGnaZozE5ratC2Nr12jt2UGbq7KuGY95gkkT5Nr7P QlAkTCyt4TIEYQ/FCiD1d6HvKJE59tarY+ga+VyyyjxeDhsob2/t6Uozzfn0gmp2BAea 2ebCdl6bZD9HrQpesANzLn3iVJ0t6GeI0W0uEcAhhlKoQjbI4C09YKx4Cw7P/AIku5Wn 77lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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; bh=BqUhxcUOvv8EZWeVoadoEfAKAvxiKy4DFaV8F/F3nRo=; b=pWMg9w6OvjXKrmtCl+hYtIGhZ3qPDbZXstG2gRaOxyqRiEl63homWSUDwCElr16eG0 avCALv/+WObBLU7WruBu5ahxMQEQc8zSIv6/w8m0/rrk40bVH+PCdWNluLZd64OjD6/j 1o9Dqh/JcdHJgQOeJG9tBBhDULZ1oGAvdPRJIPU0tVopI1hXfcEqPlR/lc7RKnWoI/NA sRTfeSfWyKX6bN55rSK9kn/whIGxYJgjjZBmZ5XV+5R7FNa30dtp49vzUpF6lxM3J12I WNxaB9TG5jT9u36NYDSyF7PtZ13nQadENptFFZtPKoGb56ovmu3b4ZOmfi/EaVA5TrEa j9oQ== X-Gm-Message-State: ACgBeo0I3FyZR4gkCQGcXhDoTGkbCh6TiNqPDoDOGX2ZVJUuGlSCTf0f kTGPp9IiYuVaMWvm3F3PtwDNdQ== X-Google-Smtp-Source: AA6agR4UATq2gDShvsXLljJKEJB7uvGsKLNEqlognTMeRcIxtphBnWCa23O0u7Vyr0cktSSkh1HKog== X-Received: by 2002:a17:90a:d804:b0:202:f247:91b0 with SMTP id a4-20020a17090ad80400b00202f24791b0mr3530610pjv.8.1663142753759; Wed, 14 Sep 2022 01:05:53 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id d8-20020a17090a6a4800b001fd7e56da4csm8460240pjm.39.2022.09.14.01.05.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Sep 2022 01:05:53 -0700 (PDT) Date: Wed, 14 Sep 2022 08:05:49 +0000 From: Sean Christopherson To: Michael Roth Cc: Brijesh Singh , x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Joerg Roedel , Tom Lendacky , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Andy Lutomirski , Dave Hansen , Sergio Lopez , Peter Gonda , Peter Zijlstra , Srinivas Pandruvada , David Rientjes , Dov Murik , Tobin Feldman-Fitzthum , Borislav Petkov , Vlastimil Babka , "Kirill A . Shutemov" , Andi Kleen , tony.luck@intel.com, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com, jarkko@profian.com Subject: Re: [PATCH Part2 v5 39/45] KVM: SVM: Introduce ops for the post gfn map and unmap Message-ID: References: <20210820155918.7518-1-brijesh.singh@amd.com> <20210820155918.7518-40-brijesh.singh@amd.com> <4e41dcff-7c7b-cf36-434a-c7732e7e8ff2@amd.com> <20220908212114.sqne7awimfwfztq7@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220908212114.sqne7awimfwfztq7@amd.com> ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Y45pldWa; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf11.hostedemail.com: domain of seanjc@google.com designates 209.85.216.45 as permitted sender) smtp.mailfrom=seanjc@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663142755; a=rsa-sha256; cv=none; b=EgQVSAJzDu5EEstEhe/rbYsRmX7vVlMrxLXm1aHxEj/EC6SW26aUU028QZXe0CJzS21WUJ a9zYmWNr9Wn4O7L2gSQoZzP1bw3PcVP5j7glwSLCre7RIzTSh6OJzb40LMH6+RaJu65wSc dT7IL5/bSIkM/1vRLVKa89YS8PyQKbc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663142755; 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=BqUhxcUOvv8EZWeVoadoEfAKAvxiKy4DFaV8F/F3nRo=; b=cKh1BOkj6M3b8NGL3CLRGNBkNKmSHYvyM7fMQ8q9sgXkdeZx6X15WBBaM8Kq2A+oJhElwn K1tCh94+XgTcDcA2pa/2J1AHx4h6Uo6g9MKnUXi06AL7WKsVxE8vsZuNx+bz4UOj9jafX4 +rpKXBOZmUk1qoX7LuLhGLA3UPgDHQA= X-Rspam-User: Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Y45pldWa; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf11.hostedemail.com: domain of seanjc@google.com designates 209.85.216.45 as permitted sender) smtp.mailfrom=seanjc@google.com X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 1483F4008F X-Stat-Signature: qriuqqhwwrbnfbtb8ezi7q8taacar71f X-HE-Tag: 1663142754-793468 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 Thu, Sep 08, 2022, Michael Roth wrote: > On Fri, Oct 15, 2021 at 05:16:28PM +0000, Sean Christopherson wrote: > So in the context of this interim solution, we're trying to look for a > solution that's simple enough that it can be used reliably, without > introducing too much additional complexity into KVM. There is one > approach that seems to fit that bill, that Brijesh attempted in an > earlier version of this series (I'm not sure what exactly was the > catalyst to changing the approach, as I wasn't really in the loop at > the time, but AIUI there weren't any showstoppers there, but please > correct me if I'm missing anything): > > - if the host is writing to a page that it thinks is supposed to be > shared, and the guest switches it to private, we get an RMP fault > (actually, we will get a !PRESENT fault, since as of v5 we now > remove the mapping from the directmap as part of conversion) > - in the host #PF handler, if we see that the page is marked private > in the RMP table, simply switch it back to shared > - if this was a bug on the part of the host, then the guest will see As discussed off-list, attempting to fix up RMP violations in the host #PF handler is not a viable approach. There was also extensive discussion on-list a while back: https://lore.kernel.org/all/8a244d34-2b10-4cf8-894a-1bf12b59cf92@www.fastmail.com > AIUI, this is still sort of an open question, but you noted how nuking > the directmap without any formalized interface for letting the kernel > know about it could be problematic down the road, which also sounds > like the sort of thing more suited for having UPM address at a more > general level, since there are similar requirements for TDX as well. > > AIUI there are 2 main arguments against splitting the directmap: > a) we can't easily rebuild it atm > b) things like KSM might still tries to access private pages > > But unmapping also suffers from a), since we still end up splitting the > directmap unless we remove pages in blocks of 2M. But for UPM, it's easy to rebuild the direct map since there will be an explicit, kernel controlled point where the "inaccesible" memfd releases the private page. > But nothing prevents a guest from switching a single 4K page to private, in > which case we are forced to split. That would be normal behavior on the part > of the guest for setting up GHCB pages/etc, so we still end up splitting the > directmap over time. The host actually isn't _forced_ to split with UPM. One option would be to refuse to split the direct map and instead force userspace to eat the 2mb allocation even though it only wants to map a single 4kb chunk into the guest. I don't know that that's a _good_ option, but it is an option.