Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp5447657pxu; Thu, 22 Oct 2020 02:33:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzLUTvkvAy7BeFAI82XHhbyW6Dbd/SATwxCMrfEaHCj7gyYwqCtqMbtA5EzhNdzYRuafPd+ X-Received: by 2002:a17:906:824b:: with SMTP id f11mr1356430ejx.16.1603359190707; Thu, 22 Oct 2020 02:33:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603359190; cv=none; d=google.com; s=arc-20160816; b=HF3K3s/Eu8+kl5B3If+u3XHlwuqC4T0w/rsQyjUXY5+Bc0npeTB4Sqb8jLp/oZa7FU UNkb3i+HZv+Xu4cKLjeek3R3ZojUZG8Xx30ovUCJl0wPNPTdYSexjhw+kzHt1cSnxvn3 MqQT0PWT2yLgRBIbo2KFbqydZQTtM3UFkl19pIkBnRkc/DcSnzAm/U3nJqHeFuKiYlZj Z/QXZkB+24FPUIvQBIXxB9HDf1MnuNMLUv71obt0nQHScfN2LqL63ITMc78ClEdIVAer WmHcElDGLmg2Kx03bDSRA30ncRB4uslydsJ7OEdGOIq3QXEsC1NmjJuwGPFF6XCMa258 GgYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=9Je2jFvCO27StOIkKgrouHunvyqoP9JExaghhikO6Vs=; b=QSBcRd2gp1a4Kq39EcljECI20veQ3BXzwF2+4u/MQOIra/oRUdO488NzjlaHmTCNi5 rXel/Qh+0dGmMZGi4B3M9+WvS6G2ZapJ8m4tiQBKiDNsgVEyyLj5V535OqgP0FejNLUs riNVK8HkmM0dtbAcbHlgWTBiKqVJeqF/qZyINFtL/G/G8hRCRJTr4wa7Aiae9mgZBUKG 54MFFu6t32beVz/JCj8hSxz+qK+KueRU/l/LItQrOEnZeaaxFmYOHOtz5ZAPNpAHbmt/ lvAlI5iQXE60Mh70Y2ra4L9Y8hnBMN2eLPRos6Yo9faQeHBMalpQEFXlBbBXWX650JWw SsKA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=XaN2Q36U; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t14si600009eds.425.2020.10.22.02.32.48; Thu, 22 Oct 2020 02:33:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=XaN2Q36U; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2510007AbgJVJDu (ORCPT + 99 others); Thu, 22 Oct 2020 05:03:50 -0400 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:20388 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2510000AbgJVJDt (ORCPT ); Thu, 22 Oct 2020 05:03:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603357427; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9Je2jFvCO27StOIkKgrouHunvyqoP9JExaghhikO6Vs=; b=XaN2Q36UBWAWSz1JBzX1qe/Kil0FXQ/tEKPuUghytRE4h1xphe0OoA+MUUt6INTCSVMDQD QN4T46p4Lkdmv6REnSI7NFX4zB7F3cmtf64DgCvijDCo7ZSNoGojefqVEy4FhqfPl0sNxc 7xOeMD/8Cx33tjR9jjhhWrRZppER19o= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-454-_Dl5cYq1PRSS6OjWqA_KDw-1; Thu, 22 Oct 2020 05:03:45 -0400 X-MC-Unique: _Dl5cYq1PRSS6OjWqA_KDw-1 Received: by mail-wr1-f72.google.com with SMTP id f11so360248wro.15 for ; Thu, 22 Oct 2020 02:03:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=9Je2jFvCO27StOIkKgrouHunvyqoP9JExaghhikO6Vs=; b=Jt2XMzX5iSDutz8zoaKFGmsqTqgxZuvjQKJg4Qg+fVZWFw5JuEnZzIQvKKMFYlX4X8 +SVKuSIjoF/3w4U5bmYTxbJrYEbBgEOKxoGldC+WCl6abIHTt+ofBYxS6NG3Cx0/hou/ +nep74F5RPgDyVV7BFyDVWGtlsW0LcSu1apM6cnbzziIMnoxe2DWs4yfZurcnzEzvK/R 7esm4XhntyQMBO2t+ValxIfi/XTkwAzQX3BEuXHws0Ov4MJm7yoLibEqZN9suP2x1VAq HGPmqFclyvQ6G7Wgoy6yiNwkv4S+8xOigyQJqgRYf25MMxIroZLRVCS3Ez0z/jF+p6cy Qjag== X-Gm-Message-State: AOAM5314xm8ZclG2lsM8GVxLFINc3WfXr2dZIHW/L5NIsTRl4acyzrSR b4TNEEyvb7/4imO6ucL0vJ972WLUtERlWs4luJ+CP1oJxdLDjC+Wxm00ZkRIqHP3IX+UWjq6SoC JmNjOdVYfRx6uDomg7GZ/KNFD X-Received: by 2002:adf:e849:: with SMTP id d9mr1708252wrn.25.1603357423645; Thu, 22 Oct 2020 02:03:43 -0700 (PDT) X-Received: by 2002:adf:e849:: with SMTP id d9mr1708216wrn.25.1603357423370; Thu, 22 Oct 2020 02:03:43 -0700 (PDT) Received: from vitty.brq.redhat.com (g-server-2.ign.cz. [91.219.240.2]) by smtp.gmail.com with ESMTPSA id 130sm2484578wmd.18.2020.10.22.02.03.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Oct 2020 02:03:41 -0700 (PDT) From: Vitaly Kuznetsov To: Sean Christopherson Cc: Paolo Bonzini , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 05/10] KVM: VMX: Invalidate hv_tlb_eptp to denote an EPTP mismatch In-Reply-To: <20201021163843.GC14155@linux.intel.com> References: <20201020215613.8972-1-sean.j.christopherson@intel.com> <20201020215613.8972-6-sean.j.christopherson@intel.com> <87wnzj4utj.fsf@vitty.brq.redhat.com> <20201021163843.GC14155@linux.intel.com> Date: Thu, 22 Oct 2020 11:03:40 +0200 Message-ID: <878sby4opf.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Sean Christopherson writes: > On Wed, Oct 21, 2020 at 02:39:20PM +0200, Vitaly Kuznetsov wrote: >> Sean Christopherson writes: >> >> > Drop the dedicated 'ept_pointers_match' field in favor of stuffing >> > 'hv_tlb_eptp' with INVALID_PAGE to mark it as invalid, i.e. to denote >> > that there is at least one EPTP mismatch. Use a local variable to >> > track whether or not a mismatch is detected so that hv_tlb_eptp can be >> > used to skip redundant flushes. >> > >> > No functional change intended. >> > >> > Signed-off-by: Sean Christopherson >> > --- >> > arch/x86/kvm/vmx/vmx.c | 16 ++++++++-------- >> > arch/x86/kvm/vmx/vmx.h | 7 ------- >> > 2 files changed, 8 insertions(+), 15 deletions(-) >> > >> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c >> > index 52cb9eec1db3..4dfde8b64750 100644 >> > --- a/arch/x86/kvm/vmx/vmx.c >> > +++ b/arch/x86/kvm/vmx/vmx.c >> > @@ -498,13 +498,13 @@ static int hv_remote_flush_tlb_with_range(struct kvm *kvm, >> > struct kvm_vmx *kvm_vmx = to_kvm_vmx(kvm); >> > struct kvm_vcpu *vcpu; >> > int ret = 0, i; >> > + bool mismatch; >> > u64 tmp_eptp; >> > >> > spin_lock(&kvm_vmx->ept_pointer_lock); >> > >> > - if (kvm_vmx->ept_pointers_match != EPT_POINTERS_MATCH) { >> > - kvm_vmx->ept_pointers_match = EPT_POINTERS_MATCH; >> > - kvm_vmx->hv_tlb_eptp = INVALID_PAGE; >> > + if (!VALID_PAGE(kvm_vmx->hv_tlb_eptp)) { >> > + mismatch = false; >> > >> > kvm_for_each_vcpu(i, vcpu, kvm) { >> > tmp_eptp = to_vmx(vcpu)->ept_pointer; >> > @@ -515,12 +515,13 @@ static int hv_remote_flush_tlb_with_range(struct kvm *kvm, >> > if (!VALID_PAGE(kvm_vmx->hv_tlb_eptp)) >> > kvm_vmx->hv_tlb_eptp = tmp_eptp; >> > else >> > - kvm_vmx->ept_pointers_match >> > - = EPT_POINTERS_MISMATCH; >> > + mismatch = true; >> > >> > ret |= hv_remote_flush_eptp(tmp_eptp, range); >> > } >> > - } else if (VALID_PAGE(kvm_vmx->hv_tlb_eptp)) { >> > + if (mismatch) >> > + kvm_vmx->hv_tlb_eptp = INVALID_PAGE; >> > + } else { >> > ret = hv_remote_flush_eptp(kvm_vmx->hv_tlb_eptp, range); >> > } >> >> Personally, I find double negations like 'mismatch = false' hard to read >> :-). > > Paolo also dislikes double negatives (I just wasted a minute of my life trying > to work a double negative into that sentence). > >> What if we write this all like >> >> if (!VALID_PAGE(kvm_vmx->hv_tlb_eptp)) { >> kvm_vmx->hv_tlb_eptp = to_vmx(vcpu0)->ept_pointer; >> kvm_for_each_vcpu() { >> tmp_eptp = to_vmx(vcpu)->ept_pointer; >> if (!VALID_PAGE(tmp_eptp) || tmp_eptp != kvm_vmx->hv_tlb_eptp) >> kvm_vmx->hv_tlb_eptp = INVALID_PAGE; >> if (VALID_PAGE(tmp_eptp)) >> ret |= hv_remote_flush_eptp(tmp_eptp, range); >> } >> } else { >> ret = hv_remote_flush_eptp(kvm_vmx->hv_tlb_eptp, range); >> } >> >> (not tested and I've probably missed something) > > It works, but doesn't optimize the case where one or more vCPUs has an invalid > EPTP. E.g. if vcpuN->ept_pointer is INVALID_PAGE, vcpuN+1..vcpuZ will flush, > even if they all match. Now, whether or not it's worth optimizing > that case... Yea. As KVM is already running on Hyper-V, nesting on top of it is likely out of question so IMO it's not even worth optimizing... > > This is also why I named it "mismatch", i.e. it tracks whether or not there was > a mismatch between valid EPTPs, not that all EPTPs matched. > > What about replacing "mismatch" with a counter that tracks the number of unique, > valid PGDs that are encountered? > > if (!VALID_PAGE(kvm_vmx->hv_tlb_pgd)) { > unique_valid_pgd_cnt = 0; > > kvm_for_each_vcpu(i, vcpu, kvm) { > tmp_pgd = to_vmx(vcpu)->hv_tlb_pgd; > if (!VALID_PAGE(tmp_pgd) || > tmp_pgd == kvm_vmx->hv_tlb_pgd) > continue; > > unique_valid_pgd_cnt++; > > if (!VALID_PAGE(kvm_vmx->hv_tlb_pgd)) > kvm_vmx->hv_tlb_pgd = tmp_pgd; > > if (!ret) > ret = hv_remote_flush_pgd(tmp_pgd, range); > > if (ret && unique_valid_pgd_cnt > 1) > break; > } > if (unique_valid_pgd_cnt > 1) > kvm_vmx->hv_tlb_pgd = INVALID_PAGE; > } else { > ret = hv_remote_flush_pgd(kvm_vmx->hv_tlb_pgd, range); > } > > > Alternatively, the pgd_cnt adjustment could be used to update hv_tlb_pgd, e.g. > > if (++unique_valid_pgd_cnt == 1) > kvm_vmx->hv_tlb_pgd = tmp_pgd; > > I think I like this last one the most. It self-documents what we're tracking > as well as the relationship between the number of valid PGDs and > hv_tlb_pgd. Both approaches look good to me, thanks! > > I'll also add a few comments to explain how kvm_vmx->hv_tlb_pgd is used. > > Thoughts? > >> > @@ -3042,8 +3043,7 @@ static void vmx_load_mmu_pgd(struct kvm_vcpu *vcpu, unsigned long pgd, >> > if (kvm_x86_ops.tlb_remote_flush) { >> > spin_lock(&to_kvm_vmx(kvm)->ept_pointer_lock); >> > to_vmx(vcpu)->ept_pointer = eptp; >> > - to_kvm_vmx(kvm)->ept_pointers_match >> > - = EPT_POINTERS_CHECK; >> > + to_kvm_vmx(kvm)->hv_tlb_eptp = INVALID_PAGE; >> > spin_unlock(&to_kvm_vmx(kvm)->ept_pointer_lock); >> > } >> > >> > diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h >> > index 3d557a065c01..e8d7d07b2020 100644 >> > --- a/arch/x86/kvm/vmx/vmx.h >> > +++ b/arch/x86/kvm/vmx/vmx.h >> > @@ -288,12 +288,6 @@ struct vcpu_vmx { >> > } shadow_msr_intercept; >> > }; >> > >> > -enum ept_pointers_status { >> > - EPT_POINTERS_CHECK = 0, >> > - EPT_POINTERS_MATCH = 1, >> > - EPT_POINTERS_MISMATCH = 2 >> > -}; >> > - >> > struct kvm_vmx { >> > struct kvm kvm; >> > >> > @@ -302,7 +296,6 @@ struct kvm_vmx { >> > gpa_t ept_identity_map_addr; >> > >> > hpa_t hv_tlb_eptp; >> > - enum ept_pointers_status ept_pointers_match; >> > spinlock_t ept_pointer_lock; >> > }; >> >> -- >> Vitaly >> > -- Vitaly