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 A08FEC433EF for ; Sat, 13 Nov 2021 18:35:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 800CB61073 for ; Sat, 13 Nov 2021 18:35:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233692AbhKMShx (ORCPT ); Sat, 13 Nov 2021 13:37:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44822 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230363AbhKMSht (ORCPT ); Sat, 13 Nov 2021 13:37:49 -0500 Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 76B1FC061766 for ; Sat, 13 Nov 2021 10:34:57 -0800 (PST) Received: by mail-pf1-x431.google.com with SMTP id x64so11310234pfd.6 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=ICTps1nsYdEwi//Jd2mq+K+rfG+oo6up7UQK+7KAHPzEWu6GbiPQ0/6IFsTCCceDL7 kwZuODyWzjtnpJ13MMZymcT5iskMfgEZRqWSyA7qDzgCgAK3FewZz82gQnTIH+vVDk0t S75J5Ok5ieWZ5rFbLNJ7WebsOsXZsyXia5mLf7RU8XGXIFLtuY9PEiO054l8GDlFs+oL ViioEsUPGvkIwqSnMsA0AxvLgBktws8Brr2+VCJ4+wFBPt9aVDIPLgxQFDNS+++8JXNG oG8L6SPSA6es6ZuXol0gCqkiIxw30g0eaH65t/myibTApHNhdV/hBK+2L8+gRumWb46l 2qMQ== X-Gm-Message-State: AOAM533xibZKr4NgdH82CSUlBDCeckLMAu90d6Y8BIo7J8qu6JKH2mmQ fkuzr8TkOePNkPQwCtvMXxiwiw== 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: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.