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 C3E07C433F5 for ; Mon, 15 Nov 2021 16:16:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 607B361BE1 for ; Mon, 15 Nov 2021 16:16:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 607B361BE1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id E657A6B0073; Mon, 15 Nov 2021 11:16:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DED786B007B; Mon, 15 Nov 2021 11:16:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C3FAF6B007E; Mon, 15 Nov 2021 11:16:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0241.hostedemail.com [216.40.44.241]) by kanga.kvack.org (Postfix) with ESMTP id AF8D06B0073 for ; Mon, 15 Nov 2021 11:16:37 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 63C6C7FAC1 for ; Mon, 15 Nov 2021 16:16:37 +0000 (UTC) X-FDA: 78811667634.13.404B911 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf25.hostedemail.com (Postfix) with ESMTP id 38770B00019C for ; Mon, 15 Nov 2021 16:16:22 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id DFA26212BF; Mon, 15 Nov 2021 16:16:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1636992993; h=from:from:reply-to: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; bh=7b7eH+fwmM30RusUMjRrdf/DCj90saq7UtYZ8DAMnVE=; b=PK/wWoUiH56BbJbfG6JFCeIiStKIJWdxb5ZDv/piXk065YE6yywS9Bfdk2pqZ5Euf6DbkX iB1AudlevlB2SVlVd2wuW6+GgrPSLyXciMm7fJ8HZNPJz1A0KlynGFhnfHpkHg/lm/xk5P eM2Mla4Kct4DF1At+fRfQSrNczrqeQg= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1636992993; h=from:from:reply-to: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; bh=7b7eH+fwmM30RusUMjRrdf/DCj90saq7UtYZ8DAMnVE=; b=EtSwPakln53v33h6PvPpBNHLN4ca1UjxiDmIwWirzpQeCkMCqu/6QcQ5xnLJChPfnaFUzl nYjnxcD5gyDk3+DA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id B510A139EC; Mon, 15 Nov 2021 16:16:32 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id VwdfKuCHkmH+eAAAMHmgww (envelope-from ); Mon, 15 Nov 2021 16:16:32 +0000 Date: Mon, 15 Nov 2021 17:16:31 +0100 From: Joerg Roedel To: Sean Christopherson Cc: Borislav Petkov , Dave Hansen , Peter Gonda , 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 , 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> <061ccd49-3b9f-d603-bafd-61a067c3f6fa@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 38770B00019C X-Stat-Signature: oufnko3xjp8mwua1usmk97mkxjyoqhsb Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b="PK/wWoUi"; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=EtSwPakl; spf=pass (imf25.hostedemail.com: domain of jroedel@suse.de designates 195.135.220.28 as permitted sender) smtp.mailfrom=jroedel@suse.de; dmarc=pass (policy=none) header.from=suse.de X-HE-Tag: 1636992982-355329 Content-Transfer-Encoding: quoted-printable 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 at 07:48:17PM +0000, Sean Christopherson wrote: > Yes, but IMO inducing a fault in the guest because of _host_ bug is wro= ng. And what is the plan with handling this host bug? Can it be handled in a way that keeps the guest running? IMO the best way to handle this is to do it the way Peter proposed: * Convert the page from private to shared on host write access and log this event on the host side (e.g. via a trace event) * The guest will notice what happened and can decide on its own what to do, either poison the page or panic with doing a kdump that can be used for bug analysis by guest and host owner At the time the fault happens we can not reliably find the reason. It can be a host bug, a guest bug (or attack), or whatnot. So the best that can be done is collecting debug data without impacting other guests. This also saves lots of code for avoiding these faults when the outcome would be the same: A dead VM. > I disagree, this would require "new" ABI in the sense that it commits K= VM to > supporting SNP without requiring userspace to initiate any and all conv= ersions > between shared and private. Which in my mind is the big elephant in th= e room: > do we want to require new KVM (and kernel?) ABI to allow/force userspac= e to > explicitly declare guest private memory for TDX _and_ SNP, or just TDX? No, not for SNP. User-space has no say in what guest memory is private and shared, that should fundamentally be the guests decision. The host has no idea about the guests workload and how much shared memory it needs. It might be that the guest temporarily needs to share more memory. I see no reason to cut this flexibility out for SNP guests. Regards, --=20 J=F6rg R=F6del jroedel@suse.de SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 N=FCrnberg Germany =20 (HRB 36809, AG N=FCrnberg) Gesch=E4ftsf=FChrer: Ivo Totev