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 9CAD8C433F5 for ; Mon, 15 Nov 2021 17:25:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3B79361BD2 for ; Mon, 15 Nov 2021 17:25:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3B79361BD2 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 CE67D6B007B; Mon, 15 Nov 2021 12:25:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C95306B007D; Mon, 15 Nov 2021 12:25:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B84476B007E; Mon, 15 Nov 2021 12:25:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0230.hostedemail.com [216.40.44.230]) by kanga.kvack.org (Postfix) with ESMTP id A8A616B007B for ; Mon, 15 Nov 2021 12:25:50 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 57EBD8225A for ; Mon, 15 Nov 2021 17:25:50 +0000 (UTC) X-FDA: 78811842060.21.0F9E187 Received: from mail-pg1-f173.google.com (mail-pg1-f173.google.com [209.85.215.173]) by imf01.hostedemail.com (Postfix) with ESMTP id 907E05093071 for ; Mon, 15 Nov 2021 17:25:33 +0000 (UTC) Received: by mail-pg1-f173.google.com with SMTP id g28so15160992pgg.3 for ; Mon, 15 Nov 2021 09:25:49 -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=zTcl/CA5Ev6UODKtmHkLeIkZrDlcXRolMIEi+XRmo/4=; b=Ecl0cR1xR7V7WnPSUzOs7tEPw8P6cyZ335nnh7QMRz62gsdjjFoubmdkPQZg9HWsC6 V/p1WnKw07yMKVmnJmySSdDW4RE2A8/YHpHDZkgGWtFrFcjQxO8t5+Aqi/pjzl1GgOkC hrDk+k2oXpUzuuJwg1XiLvM/suOqVOj/YAIJU+NLl0gyY5fArOTbfTJhWw1CjosHBRdR FpLALiKVdw8LRNvx5HjfNzYxjm9es2xaaoMx8A7aRY5FWbzRyNhpQ2IH7aBoPzPLBnoY CfbfwKnxMlD3rKWI+D0BUnzoJghtxM0gtp8RpaEsc8Hno8aJzxPRsck0OCTmhfDuEdJV gMJw== 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=zTcl/CA5Ev6UODKtmHkLeIkZrDlcXRolMIEi+XRmo/4=; b=mEDNohzXvec351OHcgOTZd52/oD1a19Wt9A1V7wnsPJUqt4f8FESralei+3uyxr1RS LWmAPwy1xLbjiDyWj4lqrpj2I1j3n1kZUimffJwJAE1rOdqgSRzbaemG2iXUFiANTVmV e9pTYZMDuaTxTzdpLR5cjtt2L4/jY0CZvY49YLeOG4ET7cikvozE/xdux+p48gqGwdAr LERQIxZkNVJ6j778SHgbM1xt2klNK533OtbAtOPdnobuhl8Bap7zJ4Vj4zwh02DpGRi/ Wk+5wIWjdhqKjkKiv5BQls+3feS+iyj6F1T/DwyFAsVxhAfWPujy4BIe0n14Cm2+1wyf u4SA== X-Gm-Message-State: AOAM532uDVrD/iRzDG6en7x9hYF3bE+BVjx9ZoBabi6Xt3lsmigovt3Y AFLhuKPiaDdK0LqmFQqHolBkyg== X-Google-Smtp-Source: ABdhPJxWeWGi2U9i9fC6X4OCa+G3zMGesVsvaMbNPJ+jfguhVVFtD+RJxF8y7Z6fLKMDMarAgB7c6Q== X-Received: by 2002:aa7:888d:0:b0:47c:128b:ee57 with SMTP id z13-20020aa7888d000000b0047c128bee57mr34630009pfe.81.1636997148447; Mon, 15 Nov 2021 09:25:48 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id j6sm12238880pgf.60.2021.11.15.09.25.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Nov 2021 09:25:47 -0800 (PST) Date: Mon, 15 Nov 2021 17:25:43 +0000 From: Sean Christopherson To: Joerg Roedel Cc: Marc Orr , Peter Gonda , Borislav Petkov , Dave Hansen , 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, sathyanarayanan.kuppuswamy@linux.intel.com Subject: Re: [PATCH Part2 v5 00/45] Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 907E05093071 X-Stat-Signature: gep8q9pf3hrbefxepxi1iz7ak1pfgfat Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Ecl0cR1x; spf=pass (imf01.hostedemail.com: domain of seanjc@google.com designates 209.85.215.173 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1636997133-665080 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 Mon, Nov 15, 2021, Joerg Roedel wrote: > On Sat, Nov 13, 2021 at 06:34:52PM +0000, Sean Christopherson wrote: > > I'm not treating it nonchalantly, merely acknowledging that (a) some flavors of kernel > > bugs (or hardware issues!) are inherently fatal to the system, and (b) crashing the > > host may be preferable to continuing on in certain cases, e.g. if continuing on has a > > high probablity of corrupting guest data. > > The problem here is that for SNP host-side RMP faults it will often not > be clear at fault-time if it was caused by wrong guest or host behavior. > > I agree with Marc that crashing the host is not the right thing to do in > this situation. Instead debug data should be collected to do further > post-mortem analysis. Again, I am not saying that any RMP #PF violation is an immediate, "crash the host". It should be handled exactly like any other #PF due to permission violation. The only wrinkle added by the RMP is that the #PF can be due to permissions on the GPA itself, but even that is not unique, e.g. see the proposed KVM XO support that will hopefully still land someday. If the guest violates the current permissions, it (indirectly) gets a #VC. If host userspace violates permissions, it gets SIGSEGV. If the host kernel violates permissions, then it reacts to the #PF in whatever way it can. What I am saying is that in some cases, there is _zero_ chance of recovery in the host and so crashing the entire system is inevitable. E.g. if the host kernel hits an RMP #PF when vectoring a #GP because the IDT lookup somehow triggers an RMP violation, then the host is going into triple fault shutdown. [*] https://lore.kernel.org/linux-mm/20191003212400.31130-1-rick.p.edgecombe@intel.com/