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 F30D6C433EF for ; Sat, 13 Nov 2021 00:10:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7BC2A60EFD for ; Sat, 13 Nov 2021 00:10:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7BC2A60EFD 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 0CDEC6B0075; Fri, 12 Nov 2021 19:10:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 07E376B0078; Fri, 12 Nov 2021 19:10:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E39486B007B; Fri, 12 Nov 2021 19:10:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0132.hostedemail.com [216.40.44.132]) by kanga.kvack.org (Postfix) with ESMTP id D17EA6B0075 for ; Fri, 12 Nov 2021 19:10:31 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 98A098249980 for ; Sat, 13 Nov 2021 00:10:31 +0000 (UTC) X-FDA: 78801975462.17.D8976D8 Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com [209.85.167.181]) by imf03.hostedemail.com (Postfix) with ESMTP id 4B2203001A0C for ; Sat, 13 Nov 2021 00:10:22 +0000 (UTC) Received: by mail-oi1-f181.google.com with SMTP id t19so20973441oij.1 for ; Fri, 12 Nov 2021 16:10:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eKWR0Y85NN7RyQ3kGVx0D7iJn85BJCX0K42JtUXarAU=; b=JYfrhOhYB5iowTwOaEQsAuvCl/7R6EpEwANtkrLj6rABd0tsys3aea7mOPld/+PLvS lnZ9icq3oa1InotU4n42ZayV+SYueUbrC0oGp1+SPmpM39juy6KfrNpk1Pf4rBTRANq0 Ucn/np3CXWU1FoBpNmNZ8oi//yUyN/x933NJXo+85Fd/x+GNxvPpqyLiRHiNizgHYyDC wViGb08gcQ7pCgch4yZJlEhogV7AxCAo1x/Wlq7EnDSnSk3ihoFnZqaHvnc2z1KqTYDQ H01Zkd7mlwdp8BHlR+MLHR1KlyTNIvJFFqa4rFh80ZZu5DtDqNwaO1HIid09OxqCERZT gGfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eKWR0Y85NN7RyQ3kGVx0D7iJn85BJCX0K42JtUXarAU=; b=eGOVvw3ndt3HlZlJs0xGzY6TGVMZkBZkwEpDvsjTaAbjRcGq9ZEmmW1V2d7WmiBs2s sHI2uA8vQQYs2Cuz6PJs5C7mrGlvzeFpWiuG/bDp5pwXdP+SyKmS9AxCzzt/QkXH90et MxqG9xP/lOkyKomc1wuq8holLU/PqXFNyFd87nPaNtwtbkuCzMtbQlxn4MGT/ZuTfHgV 4eEdftaVA6Yz+MS1xa0bFaJpp1fhxzazlmfNvHN9l6a1tCmaLuXTQUTTVEDITXHkSWrz e5jYi7pA4xrvu9t7t0W6v3u3NeM3r2ltOlT47KG9dnrC0aYXG8aYnmlM2DAIu799e2OL 3uYQ== X-Gm-Message-State: AOAM530AGNc8V+Mf7PVXIlZMYfmvZT92NKUg6eeBNakuE4/FJsDyDgcw 5lZcZzoXs2OSHEvNm3WI0PMf3gAqYoduk5HhlQn3jA== X-Google-Smtp-Source: ABdhPJx9yxkxXBkwcUqi9sbNpn5OrCz3LM/gA5pbKkH6GuxZuW6RD9lgnKKdhAxYNPawJLvgPOHidPn+AyZzaBVvkWQ= X-Received: by 2002:aca:2319:: with SMTP id e25mr29645817oie.164.1636762230285; Fri, 12 Nov 2021 16:10:30 -0800 (PST) MIME-Version: 1.0 References: <20210820155918.7518-1-brijesh.singh@amd.com> <061ccd49-3b9f-d603-bafd-61a067c3f6fa@intel.com> In-Reply-To: From: Marc Orr Date: Fri, 12 Nov 2021 16:10:18 -0800 Message-ID: Subject: Re: [PATCH Part2 v5 00/45] Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support To: Sean Christopherson 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 4B2203001A0C X-Stat-Signature: 8raq5uyxfucono4kx1duxas5pitimexo Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=JYfrhOhY; spf=pass (imf03.hostedemail.com: domain of marcorr@google.com designates 209.85.167.181 as permitted sender) smtp.mailfrom=marcorr@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1636762222-154668 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: > > > 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.