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 19C44C433F5 for ; Tue, 16 Nov 2021 19:18:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BFBD261545 for ; Tue, 16 Nov 2021 19:18:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org BFBD261545 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 575CB6B0073; Tue, 16 Nov 2021 14:18:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 54BEC6B007B; Tue, 16 Nov 2021 14:18:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 414876B007D; Tue, 16 Nov 2021 14:18:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0031.hostedemail.com [216.40.44.31]) by kanga.kvack.org (Postfix) with ESMTP id 34E506B0073 for ; Tue, 16 Nov 2021 14:18:55 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id F01B0886C8 for ; Tue, 16 Nov 2021 19:18:54 +0000 (UTC) X-FDA: 78815755788.08.BC9F523 Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by imf01.hostedemail.com (Postfix) with ESMTP id 2E8D752AC4D6 for ; Tue, 16 Nov 2021 18:39:22 +0000 (UTC) Received: by mail-lf1-f53.google.com with SMTP id y26so55687717lfa.11 for ; Tue, 16 Nov 2021 10:39:39 -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=y8BSCacTYyDcVPM5IoKBN/fEmfxWN/lo+RC/ugsV1kA=; b=rYJ0YguBFbcmp1Tg5G/C5elRrhHlqhZPZ9s8Rgi1EyZL/mBO38rP8TLiOW+ATwSvse hx7oPPVfHIuXUqflFoLp78XS17/oAIFNICUc0clQp+DsHzreVloNA65wQQOnbMStJO7L cRJz23BZ68/NRRpFbqz0JWlQ7dBZs4VkbRuFof2ir9z4E3NFYT2j+EcVSEvD7mBaI+7n cayKlHYWqpdyX7SKzf/EHZxBnRiaA/IxQ9tqIztiqPblFl2RiruzS7/DSXEX3z38FmRW AuC05B/4Cg4W+0nfuwbanEM5/q3cutNMoV8HbSx303/tnFRkK8RaZJvdv1FWALYQOU6m tiZQ== 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=y8BSCacTYyDcVPM5IoKBN/fEmfxWN/lo+RC/ugsV1kA=; b=0BQW5q7njhPAubAkqC9OgZdMejMEOhGL5aJFQ20QPDqeG6M/fxnXJlhfwxNOKCv8e3 TwM9l7bGT4AxZKTpARQMe7rJ6HjTpgwjLNAFARcl1SG3tRg665xfJe5249JgkvHjVKOh lVF/fczznM4DNyCTByyCRQ8NZLs6s1nid30zCoKd0OPDBqAXDRwqkcJfFp847tV9RnqO keyfAZNuHuOjFLpU5UfzHVwlE/Jqq5RBm2lS9vd7H8aaPR+I3deaolnbcwTUO4lJ/Tjw SB9lWxfAzP7BhTJJRkwdhQ0LlqXwb4Fxdw+jZjoEDser7tH/eoyRsb2EpDtkXDlKVi90 YpjA== X-Gm-Message-State: AOAM531+qz1PakAxl4b5exoNhWDyatlKZ1+dH8L+gZopd/jwuA1oC0B/ tVHCYbj8nPfV40djrBmMJSO0obzqgMVhujRzj0oLGA== X-Google-Smtp-Source: ABdhPJywTYnlEyhOxCxt2a7nHxlAjR09HGR/8hsv2oGiftn1/xaXRUoDkhP1uYAcS9P5PWYcD8g2hetueUBVXSKepCg= X-Received: by 2002:a05:6512:3e12:: with SMTP id i18mr8517991lfv.456.1637087977701; Tue, 16 Nov 2021 10:39:37 -0800 (PST) MIME-Version: 1.0 References: <061ccd49-3b9f-d603-bafd-61a067c3f6fa@intel.com> <8a244d34-2b10-4cf8-894a-1bf12b59cf92@www.fastmail.com> In-Reply-To: From: Peter Gonda Date: Tue, 16 Nov 2021 11:39:25 -0700 Message-ID: Subject: Re: [PATCH Part2 v5 00/45] Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support To: Sean Christopherson Cc: Joerg Roedel , Andy Lutomirski , Marc Orr , "Dr. David Alan Gilbert" , Borislav Petkov , Dave Hansen , Brijesh Singh , "the arch/x86 maintainers" , Linux Kernel Mailing List , kvm list , linux-coco@lists.linux.dev, linux-mm@kvack.org, Linux Crypto Mailing List , Thomas Gleixner , Ingo Molnar , Tom Lendacky , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Dave Hansen , Sergio Lopez , "Peter Zijlstra (Intel)" , Srinivas Pandruvada , David Rientjes , Dov Murik , Tobin Feldman-Fitzthum , Michael Roth , Vlastimil Babka , "Kirill A . Shutemov" , Andi Kleen , Tony Luck , Sathyanarayanan Kuppuswamy , Marc Zyngier , Will Deacon , Quentin Perret Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 2E8D752AC4D6 X-Stat-Signature: 3eggque9admg68ci3qzkp3fcftkto5om Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=rYJ0YguB; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of pgonda@google.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=pgonda@google.com X-HE-Tag: 1637087962-648614 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 Tue, Nov 16, 2021 at 11:26 AM Sean Christopherson wrote: > > On Tue, Nov 16, 2021, Joerg Roedel wrote: > > But as Marc already pointed out, the kernel needs a plan B when an RMP > > happens anyway due to some bug. > > I don't see why unexpected RMP #PF is a special snowflake that needs a different > plan than literally every other type of unexpected #PF in the kernel. When I started this thread I was not trying to say we *need* to do something different for RMP faults, but that we *could* improve host reliability by doing something. Since it is possible to special case an RMP fault and prevent a panic I thought it was with discussing.