Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp96722pxb; Wed, 6 Apr 2022 23:33:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyu0MpKpiUwYTGVto4XMHd0IIdOP1sVmMBLKEB9m68Nt0r1aT0xFgWAL6IsXBHW3y9WmyGU X-Received: by 2002:a17:906:c151:b0:6e8:1e6:da3 with SMTP id dp17-20020a170906c15100b006e801e60da3mr11752946ejc.732.1649313238897; Wed, 06 Apr 2022 23:33:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649313238; cv=none; d=google.com; s=arc-20160816; b=CZKgpPI1ziNka5K3JiAGi68DpAtDlM/bbe4UNSHjKZ5xAIIxAFEMJ6f67pGaofhSA/ 1Dx9otVu6Gsi78XCwQp9kc6NdpsKlHt4rzE8sIpW/TeIocjbTTkemE+1Hp/VkEPQYVTk DWQ+r+T6TThmnsRtgASbw+bxUuAIbO0hEUFln8yOJZMyb8/q87rvn5hFrZrnRV47ThxO 3m306gGFYrfpY29/gC8cXyHHwoLt8l4jNQwwbjmBBZ8vUmfszJUdY1IHqHb47yb7n2no wYTysx/V4JB0yqHdiX9Tci3VD/53oyyoPiNufU6v9PCXtDgvSLaHmDMfN1V5xICsQjKE F/8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=8ExeZSoz4uOcRhv64xILGKa13A/AhU1gWbTDIJ/AKQs=; b=x+zI9JFD2utXtdkr+SlbN24dJZywm8K3Ga3RxQTwL39V7kEigQPKO3VzYPrq5IngCl zfyXL6GkshPak53B/4fmgcQMbZJgH79WsqawSJ64MSgsw6GeLF3CkKqdBBHOVgwrolhz qZ6r8C2Irt5FBcX0bNG0h2x6g9rML0tTZlX1SUhV5jxKH+q6U0JObGASqoa8TK4t7tI+ ztEYZKWA2r1JiaWFomOT+riNbLfklD0Ed0MWNjAVelKKwYBm+RJ95RlkSXDJGjyn+PGr u/Wbq7aeEnilwXZ3g8ZkDWbuwRcFKY4zQaXzV7TJ3BfJF2i4eme+QHdgYJqNGJ1H6n6i jEYg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="W64r/Vso"; 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=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v13-20020a50d84d000000b0041cd8414e68si7649932edj.22.2022.04.06.23.33.33; Wed, 06 Apr 2022 23:33:58 -0700 (PDT) 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=@intel.com header.s=Intel header.b="W64r/Vso"; 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=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239610AbiDGDHm (ORCPT + 99 others); Wed, 6 Apr 2022 23:07:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35134 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239625AbiDGDHd (ORCPT ); Wed, 6 Apr 2022 23:07:33 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C1BD01728A2; Wed, 6 Apr 2022 20:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649300734; x=1680836734; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=gTlEW+MnEt4Yg4ugz2gQv4geZPmPTLyREDOaBsuLWF8=; b=W64r/Vsoiiv/YzBW493ruXp5HzBPy0qzDfC/mQzXX9TJA5yTVkfKKlLq vDRfW/CGhciMFMhlVucVCth6RF7L0jw2RaVuhtbSiqDFs5FL5BfRlStom 5GOWvPN8Ag92UwlK7fq/yPuHRLlP5fGXMHfupHpK9jqI//YNntd9mP6Av GD1qqTfonJlCnTsDC9bkAwb+aVBt7S8o7U2kqyVP3FjtqKcT7mZBAPUip V2BLjjf/p6RKgaM/6REThtEuVwV4dNqgXc9lecJ4qWrxBmp2ws5JC+fTV +padftdo5av3A2OBfbTRoQ7X1jRIvw82ZulRd+DJxrsa04iapY1iSmkVF Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10309"; a="241146947" X-IronPort-AV: E=Sophos;i="5.90,241,1643702400"; d="scan'208";a="241146947" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Apr 2022 20:05:34 -0700 X-IronPort-AV: E=Sophos;i="5.90,241,1643702400"; d="scan'208";a="570852321" Received: from mgailhax-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.254.55.23]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Apr 2022 20:05:31 -0700 Message-ID: <1f66f2e10041f95d8780f294c7f951f4b518395f.camel@intel.com> Subject: Re: [RFC PATCH v5 042/104] KVM: x86/mmu: Track shadow MMIO value/mask on a per-VM basis From: Kai Huang To: isaku.yamahata@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Cc: isaku.yamahata@gmail.com, Paolo Bonzini , Jim Mattson , erdemaktas@google.com, Connor Kuehl , Sean Christopherson Date: Thu, 07 Apr 2022 15:05:29 +1200 In-Reply-To: <1c7710a87eed650e4423935012e27747fb8c9dd8.camel@intel.com> References: <1c7710a87eed650e4423935012e27747fb8c9dd8.camel@intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 (3.42.4-1.fc35) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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 Wed, 2022-04-06 at 23:06 +1200, Kai Huang wrote: > >   void kvm_mmu_reset_all_pte_masks(void) > >   { > >    u8 low_phys_bits; > > - u64 mask; > >   > >    shadow_phys_bits = kvm_get_shadow_phys_bits(); > >   > > @@ -389,9 +383,13 @@ void kvm_mmu_reset_all_pte_masks(void) > >    * PTEs and so the reserved PA approach must be disabled. > >    */ > >    if (shadow_phys_bits < 52) > > - mask = BIT_ULL(51) | PT_PRESENT_MASK; > > + shadow_default_mmio_mask = BIT_ULL(51) | PT_PRESENT_MASK; > > Hmm...  Not related to this patch, but it seems there's a bug here.  On a > MKTME > enabled system (but not TDX) with 52 physical bits, the shadow_phys_bits will > be > set to < 52 (depending on how many MKTME KeyIDs are configured by BIOS).  In > this case, bit 51 is set, but actually bit 51 isn't a reserved bit in this > case. > Instead, it is a MKTME KeyID bit.  Therefore, above setting won't cause #PF, > but > will use a non-zero MKTME keyID to access the physical address. > > Paolo/Sean, any comments here? After looking at the code more carefully, this is not correct. shadow_phys_bits will be 52 on a MKTME-enabled system. Please ignore this. -- Thanks, -Kai