Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp8795302rwb; Tue, 13 Dec 2022 10:29:24 -0800 (PST) X-Google-Smtp-Source: AA0mqf4YNOjhnWlUG3Xb8bkxmCN5LTGdMKCRcYpz/tfBWhrcokZ0aiOdkJOo1QII3nNhTXrUbvWB X-Received: by 2002:a17:902:6b47:b0:189:dd86:a1e5 with SMTP id g7-20020a1709026b4700b00189dd86a1e5mr20811408plt.68.1670956164086; Tue, 13 Dec 2022 10:29:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670956164; cv=none; d=google.com; s=arc-20160816; b=0a6mhW8SdsEAyQrsfZGKoZqSfUDUD6x9Dm52N6toemrrK2CEAjDRe2K+xriSCLqIiK m1W0GCdkcTOXIXGAlBEqgENGHMvJWB/YUzSJ7wKl2smdWUIR8rGwzKpUTZbI0/bM/5b6 n+AJ6mfsiwl+b8PhoQzwim3YstpavCoFvyzSjUc1pMQ7SblckbO6G6+vVSuzf8NP9wiR tMC/sJw9qtz76SPZzj4l3467PI9c9pxj84C8hvZKfe0YIS15h7ga01ZLGi7WMNPZv00m DTU5G4c+/gI4prYMeS0M6CRL1NwzZwc8ECPHAdSCGOrI/Vqhysdcsbhtjl0Nfn+CAzDy Mfzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=mbj0itUaH2iI2Sp/W9k9+6g0jhIxKWmgtOweAbYRTUI=; b=uhJIay/uoAiv0UHFOo519f3XZYratQ2vtseiQtNuraLD5XLiUKSiKHgUfgXGYOJvXd KVYLiMwg4l+tlccvDLjV/lM4nBz7iGpV5ktSwlkSW0d0TwnXKcmdosyTGH5zPnLtvXMv aJ9oBxup2pR22VfPe9aRkICZVPOIrnQumTgwagvlg4WqHCmkMa4g0DarPox9IPUAjl0l Z1JCu09XabJYHrpoLsma1NpD5zaHbhZXpOJ7VP3sKbjknzDWs95Cd0DGVOtW3XsAUzdU 3wf8z8UZSirOd8rBPRMEm3pmlNxY34J9HPrK8DntM8hzEnSSeKYqnGCGBTPbeBULxy1f XWaQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=sC+ng59I; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a2-20020a170902900200b001897bfe1ec1si377117plp.345.2022.12.13.10.29.14; Tue, 13 Dec 2022 10:29:24 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=sC+ng59I; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236489AbiLMSR0 (ORCPT + 72 others); Tue, 13 Dec 2022 13:17:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47856 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236616AbiLMSRA (ORCPT ); Tue, 13 Dec 2022 13:17:00 -0500 Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9BE6124F05 for ; Tue, 13 Dec 2022 10:16:02 -0800 (PST) Received: by mail-pl1-x636.google.com with SMTP id m4so671087pls.4 for ; Tue, 13 Dec 2022 10:16:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=mbj0itUaH2iI2Sp/W9k9+6g0jhIxKWmgtOweAbYRTUI=; b=sC+ng59I3Fq379InLul02c4vIKRtojDOmCdA3u1aPrX/Secw1WbygvzSnQtrcXYLRv 8VKvHC8/RMQeZSCGG/jWyFsHnoDakOTxmUStaD+UQ8VqsYKOHrI84HA18XL1CVHS8J9h HhulPQMxoeQ5eGoAEvisjEzqhhcynKVfGGNoCr63YtiyGQHXmKY96OaKEomb08NNn78O amnA22Drjb0CZ9McvmqXAFu+94KT/O2XAGO6jzMnzDHE6X30XS5Wm/xpxnd0IeOqdqss oJZHunF1x1iV3VJHnI5ndOfeRV3QYopm0EUclP+FrLqT9kFY93zPSesA2dWEiSOvtQZp hFkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mbj0itUaH2iI2Sp/W9k9+6g0jhIxKWmgtOweAbYRTUI=; b=Ep8yy4UtVF31BsvyRft2ZXktBzu5yWnNEB1SKfnk1oui1etVVjmmc3KWBhl4zcFnpC WHgzAxBCSWYVx9lqtXdw0B6D645mdZewA6bpGHh+5uyuCBPiuWXQIlYaSdF2KRdbq7H6 43ppMjfybUffMp/Q7epVAtoxcd64jRQHXBZv1MAn9qHv0f8mcIzSs5C21APX/oesGMHm bqphHYsVRAu/vnGqP2sWGmWOir9M4grw7c+lp4jRjnG7Qaij5NrKd9InXuvKk4lwvv4l vuLdiH0S8sDgr8wHbPk6YCJdK613pl8pODEqSFQ7big4mvqiE8fIZTdwoBd6dFaB7oK5 rJsg== X-Gm-Message-State: ANoB5pkbs0xLDexRrsEejfwsA87HvBtf0or0j7koCwU1Mfuaz57Dm0hh AkuM3bh/SXe9WzHrBuLdH5D1ag== X-Received: by 2002:a17:902:da8d:b0:189:3a04:4466 with SMTP id j13-20020a170902da8d00b001893a044466mr431766plx.2.1670955362013; Tue, 13 Dec 2022 10:16:02 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id s14-20020a170902ea0e00b00189c26719cdsm157289plg.272.2022.12.13.10.16.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Dec 2022 10:16:00 -0800 (PST) Date: Tue, 13 Dec 2022 18:15:56 +0000 From: Sean Christopherson To: David Matlack Cc: Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Robert Hoo , Greg Thelen , Ben Gardon , Mingwei Zhang Subject: Re: [PATCH 4/5] KVM: x86/mmu: Don't install TDP MMU SPTE if SP has unexpected level Message-ID: References: <20221213033030.83345-1-seanjc@google.com> <20221213033030.83345-5-seanjc@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 13, 2022, David Matlack wrote: > On Mon, Dec 12, 2022 at 7:30 PM Sean Christopherson wrote: > > > > Don't install a leaf TDP MMU SPTE if the parent page's level doesn't > > match the target level of the fault, and instead have the vCPU retry the > > faulting instruction after warning. Continuing on is completely > > unnecessary as the absolute worst case scenario of retrying is DoSing > > the vCPU, whereas continuing on all but guarantees bigger explosions, e.g. > > Would it make sense to kill the VM instead via KVM_BUG()? No, because if bug that hits this escapes to a release, odds are quite high that retrying will succeed. E.g. the fix earlier in this series is for a rare corner case that I was able to hit consistently only by hacking KVM to effectively synchronize the page fault and zap. Other than an extra page fault, no harm has been done to the guest, e.g. there's no need to kill the VM to protect it from data corruption.