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 0AB24C433EF for ; Sat, 13 Nov 2021 18:35:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 87B96611C0 for ; Sat, 13 Nov 2021 18:34:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 87B96611C0 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 E434D6B0075; Sat, 13 Nov 2021 13:34:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DF3056B0078; Sat, 13 Nov 2021 13:34:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CBB376B007B; Sat, 13 Nov 2021 13:34:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0228.hostedemail.com [216.40.44.228]) by kanga.kvack.org (Postfix) with ESMTP id BE1146B0075 for ; Sat, 13 Nov 2021 13:34:58 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 85AFE183BCDA3 for ; Sat, 13 Nov 2021 18:34:58 +0000 (UTC) X-FDA: 78804758676.18.DCAAD7D Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) by imf27.hostedemail.com (Postfix) with ESMTP id 1A9B570000B0 for ; Sat, 13 Nov 2021 18:34:57 +0000 (UTC) Received: by mail-pg1-f174.google.com with SMTP id n23so10820384pgh.8 for ; Sat, 13 Nov 2021 10:34:57 -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=zSxj8eRX0cnZYbcOeH01JUaZh5KPAX40UEWt0+2IJiM=; b=NGgVBK0eIHprea6mvLCk+5HiStmbJEiIRPJQRX+o5aC3tSlJkXN3kamK5bFgym//aa 6KOd4p512Oy5/fNf3MbduQ39nKhukOr7CCnKpuyi3YhCyWaEAc6Dd2TIM9s0HuaItkbq vNfddajdmOPiGl0PyNKqY2hon4hYsuQHJvhuqfG5uxdLPfAW6rOrZBLLlaSWlNhQss1q BCI7DLCqDKJv+wkROMwzJQ+xn2NZF6njWm8eA0hhyzjuuElnSrWIsaN92o+K/j7sRM3v bcz/TnaZabI69pok77atryvFxVbqUynR3hethfIzf4yQMntzJm86GsFwEMwKmoogd9Em tdfQ== 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=zSxj8eRX0cnZYbcOeH01JUaZh5KPAX40UEWt0+2IJiM=; b=XyoIzRZqXGd/uXPADU3D2wiTdUSjRftLx30sKKk/4gqKDTZ4E2lpyQK7r1+hFeG6mA w66c7vkbtG8nmCdjhSBsAHIJAItW5oerozTOxxMLT1hU1OFhK1ybwaH5O/PJuujlK/mj CYB9xlZTDGtDWw5U1/fYeuZayjQkxYopC+Ao8qY/X1XmIVK+X6RejYag4+hXoftNHEZc s2JDgz3BfypswOtTavi1n4Z5ZvwM+ayIEx0NiY+FGy8VAsmERsA45nLs6uK8qh6y1L0R DZ2RavT9W/ClYEqxCT9Q6k91sqG6BR6kmCzC5jcmd1xQX53fdtgph4IGg3a9ZRMucvuu VpPg== X-Gm-Message-State: AOAM533O5jR4X59mitNT9hYYhBAimuY/M1mjuV86kZZHw/4fZIjwcXg9 bLshN99TqYl38S8VHjD/fKghHg== X-Google-Smtp-Source: ABdhPJxeDdCpGqvSMmznYnDhqmjUQVZ7YRfHUv6xQxIKfIgqzs5xPqbn0hQnNT4ChktEWJKfOne+lQ== X-Received: by 2002:a63:86c1:: with SMTP id x184mr14326986pgd.469.1636828496852; Sat, 13 Nov 2021 10:34:56 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id ml24sm8101994pjb.16.2021.11.13.10.34.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 13 Nov 2021 10:34:56 -0800 (PST) Date: Sat, 13 Nov 2021 18:34:52 +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: <061ccd49-3b9f-d603-bafd-61a067c3f6fa@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 1A9B570000B0 X-Stat-Signature: crs49nscf8ygohan633r94feohwhxf3a Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=NGgVBK0e; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of seanjc@google.com designates 209.85.215.174 as permitted sender) smtp.mailfrom=seanjc@google.com X-HE-Tag: 1636828497-190451 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, 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.