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 3DFE5C433EF for ; Tue, 23 Nov 2021 16:26:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 988B36B006C; Tue, 23 Nov 2021 11:26:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 911366B0071; Tue, 23 Nov 2021 11:26:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 78A356B0072; Tue, 23 Nov 2021 11:26:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0133.hostedemail.com [216.40.44.133]) by kanga.kvack.org (Postfix) with ESMTP id 66A226B006C for ; Tue, 23 Nov 2021 11:26:38 -0500 (EST) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 1F7BD80B7FB1 for ; Tue, 23 Nov 2021 16:26:28 +0000 (UTC) X-FDA: 78840722856.03.169BCB2 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf01.hostedemail.com (Postfix) with ESMTP id D94FD508BB98 for ; Tue, 23 Nov 2021 16:26:16 +0000 (UTC) Received: from zn.tnic (p200300ec2f14d20006ffc72651f84cb2.dip0.t-ipconnect.de [IPv6:2003:ec:2f14:d200:6ff:c726:51f8:4cb2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 614E01EC0423; Tue, 23 Nov 2021 17:26:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1637684778; h=from:from: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; bh=Bavt564BU2rM1WOQe9eoYfojylE1mxii7g1TihHieiE=; b=rHANThsDYg+AtenNwwpzB3LiACcYb8e6zoyxmOCqJ/8+j2mFwep7JYl3IsSfyTFjLD5jQ4 4IeKtnSUYa+6YgNd2S2Ka1/xx4E4hGxkNGghT+ALLZaFotMrVBxysVVL9eSZnVFsSuAdr3 B0CcC2oRh3yPxvinKattnTh8ngdmwOw= Date: Tue, 23 Nov 2021 17:26:14 +0100 From: Borislav Petkov To: Sean Christopherson Cc: Dave Hansen , Brijesh Singh , Peter Gonda , 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 Zijlstra , Srinivas Pandruvada , David Rientjes , Dov Murik , Tobin Feldman-Fitzthum , Michael Roth , Vlastimil Babka , "Kirill A . Shutemov" , Andi Kleen , tony.luck@intel.com, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com Subject: Re: [PATCH Part2 v5 00/45] Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support Message-ID: References: <20210820155918.7518-1-brijesh.singh@amd.com> <5f3b3aab-9ec2-c489-eefd-9136874762ee@intel.com> <38282b0c-7eb5-6a91-df19-2f4cfa8549ce@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Stat-Signature: mt4i66x6fpodqbxy7fjebhh39trb1zxq Authentication-Results: imf01.hostedemail.com; dkim=temperror ("DNS error when getting key") header.d=alien8.de header.s=dkim header.b=rHANThsD; dmarc=temperror reason="server fail" header.from=alien8.de (policy=temperror); spf=pass (imf01.hostedemail.com: domain of bp@alien8.de designates 5.9.137.197 as permitted sender) smtp.mailfrom=bp@alien8.de X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: D94FD508BB98 X-HE-Tag: 1637684776-998746 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 Tue, Nov 23, 2021 at 03:36:35PM +0000, Sean Christopherson wrote: > Kirill posted a few RFCs that did exactly that. It's definitely a viable approach, > but it's a bit of a dead end, One thing at a time... > e.g. doesn't help solve page migration, AFAICR, that needs a whole explicit and concerted effort with the migration helper - that was one of the approaches, at least, guest's explicit involvement, remote attestation and a bunch of other things... > is limited to struct page I'm no mm guy so maybe you can elaborate further. > doesn't capture which KVM guest owns the memory, etc... So I don't think we need this for the problem at hand. But from the sound of it, it probably is a good idea to be able to map the guest owner to the memory anyway. > https://lore.kernel.org/kvm/20210416154106.23721-1-kirill.shutemov@linux.intel.com/ Right, there it is in the last patch. Hmmkay, so we need some generic machinery which unmaps memory from the host kernel's pagetables so that it doesn't do any stray/unwanted accesses to it. I'd look in the direction of mm folks for what to do exactly, though. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette