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;
Date:   Fri, 26 May 2023 15:54:11 +0800
From:   Yan Zhao <yan.y.zhao@intel.com>
To:     Sean Christopherson <seanjc@google.com>
CC:     Robert Hoo <robert.hoo.linux@gmail.com>, <kvm@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <pbonzini@redhat.com>
Subject: Re: [PATCH v2 5/6] KVM: x86: Keep a per-VM MTRR state
Message-ID: <ZHBloxxmY/EUyswL@yzhao56-desk.sh.intel.com>
Reply-To: Yan Zhao <yan.y.zhao@intel.com>
References: <20230509134825.1523-1-yan.y.zhao@intel.com>
 <20230509135300.1855-1-yan.y.zhao@intel.com>
 <3f09e751-33fd-7d60-78cd-6857d113e8bd@gmail.com>
 <ZGxbat2mM6AfOOVv@yzhao56-desk.sh.intel.com>
 <ZG1WsnYST4zLqTnv@google.com>
 <ZG3vB052ubr1vBQA@yzhao56-desk.sh.intel.com>
 <ZG5VlRzJkcwo9Qju@google.com>
 <ZG8z493pfPIOPAT2@yzhao56-desk.sh.intel.com>
 <ZG92dWFxu+ue31Sl@google.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <ZG92dWFxu+ue31Sl@google.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?mz/KIc/tKyMQKDwjzvn/iCU/cuvpabsjfHSGWWQz3num864xOIYqPvLvDWO6?=
 =?us-ascii?Q?IkNT+LQSWIzW2pxU06w8YvonrXyyijQjRiagsVnTiyASCcVcic0/snXCHDw9?=
 =?us-ascii?Q?rT8abmU2qE6+HNRh3JJYaxqhZhPNkdxJaqW04nJ6GGAUBZrv1raSL1QqhyVx?=
 =?us-ascii?Q?7JHkd+ETtU3aIKvKp0cnTyi7G0uT03wlDkA8yRX04LqGGZlOjdv6876QGvaJ?=
 =?us-ascii?Q?eCKHwt2YcMBCC26hPKqvcvZAABcQ/Fwu1hkIP8IDwXoVL78mFUU08F19dG3D?=
 =?us-ascii?Q?gNDGC2N6qMi7H1L69GZkxmV0i3bBiCDyLebztQAZaIEzmiqKbwEGBaHnYUxl?=
 =?us-ascii?Q?OSuzW7A2b1Z0/QkgFS/Bm3LBeCSCq73HCh1Iwo1omZ8K4eP2Uln8Ju1lSXFF?=
 =?us-ascii?Q?HQ5ueumqytBdL1VIKbtC93wwONerudpB86Q329wQzlyGtVDG9+C8gVdzlIhK?=
 =?us-ascii?Q?etjcc/4j6u41CP1KxvsGBpeS11qyhpSrEsaVvH6hUjo+55407JWBQYLfQjLh?=
 =?us-ascii?Q?WLZHZ1ztkYDUDp8u+QWvUT5mDFkLIQDmBvlE8NqNugPiRNWkLHFRdiz2HG5s?=
 =?us-ascii?Q?PRgOmD1sx3mKQ7A+mSoB2uZyLHN20qLajl0InF8I3dW0ynINOEXajhmHdnpc?=
 =?us-ascii?Q?7OkidbjeCOSkqbgB3B/3ufntnEo/iO976MoJRCAilqhggaI4mXMa5kJS4Lw4?=
 =?us-ascii?Q?zmqw8fevVqnPrkzDDjBfGNjxIHZjM9+hXIvvvzeeQfnFMtLtfO5gSUoDqABA?=
 =?us-ascii?Q?fwnKO8IXootIt8UiiXOsytLpuxdPbbXofzQYM12QnNShlnbMneHp1fH1usAc?=
 =?us-ascii?Q?ligUxTWn+WSXNZSxea/kMkk+WNqDP7mlQxxuTVjmSWFZFai3B9qcpwuT/E4t?=
 =?us-ascii?Q?aFaUh0vXQP58lkCIX6dvYELacuTAfFLeaTtc5sDLfiCr0Suw5Y7ZervqxE+R?=
 =?us-ascii?Q?3jm5GLOSCQjNteWAbqagcnK3IoIF54/WOF248WHyTd0Dg916rS+cw8CN9Hyc?=
 =?us-ascii?Q?DWJnAwvhIH52RdeRA1WpL0nG9I7n34yEsUJcfyNB+zUQ0P7oRNjx48CYP6Mu?=
 =?us-ascii?Q?ujlYr5oyCAR7XL6p9J/3Ht4TOI9AG2aSE6EuOSp54HFuEnqolXsAIbdYICbA?=
 =?us-ascii?Q?hN3ql9dvEYuVvbFIAB6ZwfJd+VFySo5LiMTzr16k00NUxmzyqng+l+ZbYQ9o?=
 =?us-ascii?Q?/DXHgdvcXybAS8DCdJZBVJYls3FNh1h5yVCWI/06jR0PsPutZ9QRH95BlkOb?=
 =?us-ascii?Q?OMMSAwgcbIbgwj3bK7jRJfIkC4o5CcYNMTHaZZmUlcPww1eh89ypfLslH+dN?=
 =?us-ascii?Q?Bp/qKYJr+V87oIPc3kfyfUMnFwjlX2cS2+sRGK1slIljZyo9NFsAZrQoE7iB?=
 =?us-ascii?Q?y3Sl8lzV6cuefFSGhvCLApiU/1JZPSqS873jgHkRWlzOEVMrynuBYZxG+mFm?=
 =?us-ascii?Q?3VABmm5OHDiCSDacXjK7vzfrm2fq3cUkvYzY++6wxqBsmGcIuRtoC3OaJytM?=
 =?us-ascii?Q?hf4YEiym3zGbp2Ng0UIzT1H3Z1fnYSuLltojP1QY8Ql3F9hW2dYxuwjtkysp?=
 =?us-ascii?Q?wV5xm3CmCrBMHSAMUvFHOZt094lvh1diYXRRDi4m?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 603aefe8-3b8b-4cd2-8be5-08db5dc1e7cf
X-MS-Exchange-CrossTenant-AuthSource: DS7PR11MB5966.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2023 08:19:20.9100
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: bZWKsIv4VqgBnEX4GaxvRjOaEgIzxehzaruKYDn84b2MSw4i/9+GoTY2SE2i8kckNw8/lXmZIKjBR89JM/chUA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB7470
X-OriginatorOrg: intel.com
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_NONE,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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, May 25, 2023 at 07:53:41AM -0700, Sean Christopherson wrote:
> > > > > So, if KVM zaps SPTEs when CR0.CD is cleared (even when the quirk is enabled),
> > > > > then KVM can skip the MTRR zaps when CR0.CD=1 because KVM is ignoring the MTRRs
> > > > > and will zap when CR0.CD is cleared.  And to avoid regressing the CR0.CD case,
> > > > > if KVM honors guest PAT for the bizarro CR0.CD quirk, then KVM only needs to
> > > > > zap non-WB MTRR ranges when CR0.CD is cleared.  Since WB is weak, looking for
> > Not only non-WB ranges are required to be zapped.
> > Think about a scenario:
> > (1) one fixed MTRR range is UC initially. Its EPT entry memtype is UC, too.
> > (2) after CR0.CD=1, without zap, its EPT entry memtype is still UC.
> > (3) then guest performs MTRR disable, no zap too.
> > (4) guest updates this fixed MTRR range to WB, and performs MTRR enable.
> > (5) CR0.CD=0. we need to zap this fixed range to update the EPT memtype to WB.
> 
> KVM installs WB memtype when the quirk is enabled, thus no need to zap.  KVM
> currently zaps everything when the quirk is disabled, and I'm not proposing that
> be changed.
I didn't explain it clearly.

(1) one fixed MTRR range is UC initially. Its EPT entry memtype is UC, too. ==> EPT entry has been created here
(2) after CR0.CD=1, because of the quirk, no zap, the created EPT entry memtype is still UC.
(3) then guest performs MTRR disable, no zap too, according to our change.
(4) guest updates this fixed MTRR range to WB, and performs MTRR enable.
(5) CR0.CD=0. we need to zap this fixed range to update the EPT memtype to WB.==>we also need to zap WB range.


> It doesn't actually require non-coherent DMA within the CR0.CD=1 window though.
If we don't need to mind non-coherent DMA within the window CR0.CD=1 to CR0.CD=0,
do you think it's a good idea to do in this way...

(1) when CR0.CD=1, return guest mtrr type. 

--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -7532,12 +7532,13 @@ static u8 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio)
                return (MTRR_TYPE_WRBACK << VMX_EPT_MT_EPTE_SHIFT) | VMX_EPT_IPAT_BIT;

        if (kvm_read_cr0_bits(vcpu, X86_CR0_CD)) {
-               if (kvm_check_has_quirk(vcpu->kvm, KVM_X86_QUIRK_CD_NW_CLEARED))
-                       cache = MTRR_TYPE_WRBACK;
-               else
+               if (kvm_check_has_quirk(vcpu->kvm, KVM_X86_QUIRK_CD_NW_CLEARED)) {
+                       cache = kvm_mtrr_get_guest_memory_type(vcpu, gfn);
+                       return cache << VMX_EPT_MT_EPTE_SHIFT;
+               } else {
                        cache = MTRR_TYPE_UNCACHABLE;
-
-               return (cache << VMX_EPT_MT_EPTE_SHIFT) | VMX_EPT_IPAT_BIT;
+                       return (cache << VMX_EPT_MT_EPTE_SHIFT) | VMX_EPT_IPAT_BIT;
+               }
        }


(2) return MTRR_TYPE_WRBACK if guest mtrr has not been enabled for once
u8 kvm_mtrr_get_guest_memory_type(struct kvm_vcpu *vcpu, gfn_t gfn)
@@ -628,13 +635,23 @@ u8 kvm_mtrr_get_guest_memory_type(struct kvm_vcpu *vcpu, gfn_t gfn)
        struct mtrr_iter iter;
        u64 start, end;
        int type = -1;
        const int wt_wb_mask = (1 << MTRR_TYPE_WRBACK)
                               | (1 << MTRR_TYPE_WRTHROUGH);
 
+       if (!mtrr_state->enabled_once)
+               return MTRR_TYPE_WRBACK;
+


(3) when CR0.CD = 1 and the quirk is on, return MTRR type as if MTRR is enabled
+       ignore_disable = kvm_read_cr0_bits(vcpu, X86_CR0_CD) &&
+                        kvm_check_has_quirk(vcpu->kvm, KVM_X86_QUIRK_CD_NW_CLEARED);

-static void mtrr_lookup_start(struct mtrr_iter *iter)
+static void mtrr_lookup_start(struct mtrr_iter *iter, bool ignore_disable)
 {
-       if (!mtrr_is_enabled(iter->mtrr_state)) {
+       if (!ignore_disable && !mtrr_is_enabled(iter->mtrr_state)) {
                iter->mtrr_disabled = true;
                return;
        }

(4) Then we only need to do EPT zap when MTRR is enabled for the first time
and when MTRR fixed/var entries are changed at enabling MTRR or at CR0.CD=0
(I prefer at enabling MTRR, as seabios may do the MTRR disable/update/enable when
CR0.CD=0)


Besides, accoding to the commit message introducing KVM_QUIRK_CD_NW_CLEARED,
we can return MTRR_TYPE_WRBACK for CR0.CD=1 only when MTRR is not enbled for
once. (And I tried, it works!)

commit fb279950ba02e3210a16b11ecfa8871f3ee0ca49
Author: Xiao Guangrong <guangrong.xiao@intel.com>
Date:   Thu Jul 16 03:25:56 2015 +0800

    KVM: vmx: obey KVM_QUIRK_CD_NW_CLEARED

    OVMF depends on WB to boot fast, because it only clears caches after
    it has set up MTRRs---which is too late.

    Let's do writeback if CR0.CD is set to make it happy, similar to what
    SVM is already doing.
 
> Yes, we can ignore !X86_FEATURE_MTRR guests.  If someone wants to run such a
> setup with non-coherent DMA, they're welcome to send patches and write a lengthy
> explanation of why they want to run such insanity :-)
great :)

> 
> > > > And pieces of no-WB memory might produce more kvm_zap_gfn_range()?
> > > 
> > > Yes, but they'll be much, much more precise.  And the bajillion fixed MTRRs can
> > Could we instead keep a per-VM copy of MTRR?
> > Then, if a vCPU modifies an MTRR entry and we find it's different from that
> > in the per-VM copy, we mark that entry dirty. When CD0=0, we just zap
> > those dirty ranges. (or just zap all if there are dirty entries)
> > In theory, only one vCPU will trigger this zap in each round of MTRR update.
> 
> I don't think tracking "dirty" MTRRs releative to a per-VM copy will work because
> of the weird behavior of the quirk.  E.g. if the below happens, vCPU1's WB SPTE
> won't be zapped because MTRRx wasn't "dirty".
>
By returning MTRR type (as if MTRR is enabled) for CR0.CD=1, we can avoid to zap
entries in this window. Agree?

>      vCPU0         vCPU1
>      ----------    ----------
> 1.   MTRRx = UC 
> 2.   CR0.CD = 1    CR0.CD=1
> 3.                 SPTE = WB
> 4.                 MTRRx = UC
> 5.                 CR0.CD=0
> 
> Another problem is that while only one vCPU will trigger the zap, KVM needs to
> stall all vCPUs that dirtied MTRRs *relative to the original per-VM state*.  E.g.
> if the per-VM state for MTRRx is WB and both vCPU1 and vCPU2 dirty an MTRR and
> both clear CR0.CD, then KVM needs to stall vCPU1 and vCPU2 regardless of which
> vCPU actually does the zapping.
> 
> And when handling the transition from dirty=>clean, KVM would need to prevent
> writes to MTRRs while grabbing the snapshot of dirty MTRRs, i.e. to-be-zapped
> ranges, in order to provide stable view of the clean per-VM copy.
> 
> In other words, the net effect will essentially be what I sketched out with the
> precise zapping, but with the added downside of serializing writes to MTRRs while
> transitioning the per-VM state from dirty=>clean.
Yes, the net effect will essentially be what you sketched out in last mail.

I can try to figure out which way is more efficient before sending out next version
if you agree with the above direction, i.e.
(1) Do not consider non-coherent DMA when CR0.CD=1
(2) return MTRR_TYPE_WRBACK for CR0.CD=1 only when MTRR is not enabled for once.
(3) return MTRR type as if MTRR is enabled for CR0.CD=1