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 52044C433F5 for ; Mon, 15 Nov 2021 17:16:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CD5CD63260 for ; Mon, 15 Nov 2021 17:16:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CD5CD63260 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 464426B007B; Mon, 15 Nov 2021 12:16:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 413506B007D; Mon, 15 Nov 2021 12:16:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2DA836B007E; Mon, 15 Nov 2021 12:16:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0236.hostedemail.com [216.40.44.236]) by kanga.kvack.org (Postfix) with ESMTP id 1E33D6B007B for ; Mon, 15 Nov 2021 12:16:46 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id D77C484778 for ; Mon, 15 Nov 2021 17:16:45 +0000 (UTC) X-FDA: 78811819170.11.17E95FE Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) by imf27.hostedemail.com (Postfix) with ESMTP id 5DECD70009D2 for ; Mon, 15 Nov 2021 17:16:45 +0000 (UTC) Received: by mail-pf1-f169.google.com with SMTP id n26so11013219pff.3 for ; Mon, 15 Nov 2021 09:16:45 -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=3NVKLepWYzLSq9Cpv5qCJO3VSr1f5SzOwcseFg0x0pY=; b=ViN8wyNqVHdH+Hf9uZiVt6rzm1zmo2rrXKAIKjHBt08UAFUv9BJAAWNuMofRgCUGQ3 pSvTt7NJ6bDoFBPiaYn8UdmOLOhoCBRC9mz4/pdqJcKbq7uz+rJ0AQkNnz+4KO1DLs0Q HU5a5hhkU5p7C2S0n9dF5y8Mk3j+BCuMBOIblS2P7zdESzvV5Y9HVMDTDykC83v6Qk0i Fn1IMf5XPZ/ppn+OHgMAEheBtO3CvwWvP5wks+OYQAmdJn6WqO2qeWGXP1DoUiP3tBIj 0bYE43Iqf38tJRkO+DgbWI4wdtkRUx2Mf6ROzMGAY9Pa79Spx5521xjH6LTLH67cXDFl LNeQ== 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=3NVKLepWYzLSq9Cpv5qCJO3VSr1f5SzOwcseFg0x0pY=; b=Ystlr1j/MPRd5w5Rn82jE7p4vT2mMkl1I7+wjjyxeD/ULVyIYfPLRThrYEd5mGZcPe PET6bGIIkOcMT0LzIJ0vkNqvsI4lEiGsKG/4xEMmKU34Z7ny2P1BRc5GA/BOvKAqs/mM JrxwQXOP2lLvmpO9HTrvsIFZpbOm9jUd9kFHeWUCyHiZoTAKF2BCwsvLNn8qaDD43OfQ 6fPcjRehQ44yPtzasX8bA5yfL3WkE2J/tysxMg+33dJ3WCnhxxml+7SuJN/RaN9z1k+X PnpjxF/jtrm8H3XSgs2FJtI0op6i1Xq8RdXXdcRWDFo79aNwsuJ0rNc6Uq+98/zmj5p6 M9bg== X-Gm-Message-State: AOAM533wObkeiLUCagvuD0XAaYUFlMmP7JG2FAl/pHfM+QP7MeKO45rF TC7GAjGUzC3dsExiTDxtGndT3Q== X-Google-Smtp-Source: ABdhPJyKc9UQWUIc7Wr3sPqTISPItmNSDSwgcqkezQohZCsJMhsK1Nvfuw30uGNo+HWmOQFuW461xA== X-Received: by 2002:a63:4d3:: with SMTP id 202mr328555pge.36.1636996603928; Mon, 15 Nov 2021 09:16:43 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id o28sm3060761pgn.85.2021.11.15.09.16.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Nov 2021 09:16:43 -0800 (PST) Date: Mon, 15 Nov 2021 17:16:39 +0000 From: Sean Christopherson To: Marc Orr Cc: 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 , 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, 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: 5DECD70009D2 X-Stat-Signature: jk55irjn6bx1u1mnydghjuoot3g678xc Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ViN8wyNq; spf=pass (imf27.hostedemail.com: domain of seanjc@google.com designates 209.85.210.169 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1636996605-259110 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 Sat, Nov 13, 2021, Marc Orr wrote: > On Sat, Nov 13, 2021 at 10:35 AM Sean Christopherson wrote: > > > > On Fri, Nov 12, 2021, Marc Orr wrote: > > > > > > If *it* is the host kernel, then you probably shouldn't do that - > > > > > > otherwise you just killed the host kernel on which all those guests are > > > > > > running. > > > > > > > > > > I agree, it seems better to terminate the single guest with an issue. > > > > > Rather than killing the host (and therefore all guests). So I'd > > > > > suggest even in this case we do the 'convert to shared' approach or > > > > > just outright terminate the guest. > > > > > > > > > > Are there already examples in KVM of a KVM bug in servicing a VM's > > > > > request results in a BUG/panic/oops? That seems not ideal ever. > > > > > > > > Plenty of examples. kvm_spurious_fault() is the obvious one. Any NULL pointer > > > > deref will lead to a BUG, etc... And it's not just KVM, e.g. it's possible, if > > > > unlikely, for the core kernel to run into guest private memory (e.g. if the kernel > > > > botches an RMP change), and if that happens there's no guarantee that the kernel > > > > can recover. > > > > > > > > I fully agree that ideally KVM would have a better sense of self-preservation, > > > > but IMO that's an orthogonal discussion. > > > > > > I don't think we should treat the possibility of crashing the host > > > with live VMs nonchalantly. It's a big deal. Doing so has big > > > implications on the probability that any cloud vendor wil bee able to > > > deploy this code to production. And aren't cloud vendors one of the > > > main use cases for all of this confidential compute stuff? I'm > > > honestly surprised that so many people are OK with crashing the host. > > > > 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. > > I disagree. Crashing the host -- and _ALL_ of its VMs (including > non-confidential VMs) -- is not preferable to crashing a single SNP > VM. We're in violent agreement. I fully agree that, when allowed by the architecture, injecting an error into the guest is preferable to killing the VM, which is in turn preferable to crashing the host. What I'm saying is that there are classes of bugs where injecting an error is not allowed/feasible, and where killing an individual VM is not correct/feasible. The canonical example of this escalating behavior is an uncorrectable ECC #MC. If the bad page is guest memory and the guest vCPU model supports MCA, then userspace can inject an #MC into the guest so that the guest can take action and hopefully not simply die. If the bad page is in the guest but the guest doesn't support #MC injection, the guest effectively gets killed. And if the #MC is in host kernel memory that can't be offlined, e.g. hits the IDT, then the whole system comes crashing down. > Especially when that SNP VM is guaranteed to detect the memory corruption and > react accordingly. For the record, we can make no such guarantees about the SNP VM. Yes, the VM _should_ do the right thing when handed a #VC, but bugs happen, otherwise we wouldn't be having this discussion.