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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3A298C433EF for ; Thu, 7 Apr 2022 17:44:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346565AbiDGRqg (ORCPT ); Thu, 7 Apr 2022 13:46:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46724 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346548AbiDGRqc (ORCPT ); Thu, 7 Apr 2022 13:46:32 -0400 Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0ADD622C8DC for ; Thu, 7 Apr 2022 10:44:31 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id s137so2829976pgs.5 for ; Thu, 07 Apr 2022 10:44:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=qtoCtjXmVQ0hZo+pdgUMIKZ+OC7BYRWQN9tD6eVQtks=; b=Ev+c+8F1X8VSZoYa+u+L7bRSkLtSGbgtXQMchuEWerfAy2WqXdaO4e7p28uSMMtQgm pDR0dADnMTGQo9FfSSyJnIzwK0HUiHup+PIVo4DZ+9RHdkJ/CJuJ5oOU+jL9mYIUn/1O DG1Pc7TDGx35uQZx8en4XtMgq2PaZvKjP1Qkq2WqDUuaROtkdhl6WNRe5GMPm/4Z5qdI 42QrrKeAzAS/UtpN0G0OQZ2GG+Ah2MGybWoH7cuGo/wEnPyJeo0/IFMppHHGsu6w6e3j At3TAzfOxOs3r1wCZK6eaw2NPU53IOz5maScWNTiw7PapkK7/zSMaeTuKG8eEgSr1HGN YRXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=qtoCtjXmVQ0hZo+pdgUMIKZ+OC7BYRWQN9tD6eVQtks=; b=pA7nOcD0tHCDdgDU0VD87tEMafME057qdAH5FEhXuvEMhIITvL1beL6RALB6PopEvp hX9tNYeMJgtyiedqGRK/BJmkUixxjNA6IZh3Ger4ZtVmKGs67zCgZ8isZOOE0DI6UtGA VEEUpFg2EIRPi0bDZ5mJexeRCjFTBakWOYYniTOqTirde6F0W9G39zz7VhzcvyL65FRt 0ZsdHohdCA+XIdx69O5oF+vxb6K+nWhy5G/z9FdCiUXbIect6zjinu/0BZNva6Dl7M1k nlSJ6WlF7bnd40wUD9MvO5jnApvhHMhqQ04j1fXqPk1DYauKAaUglLVuODV4jWytgYVs V5xg== X-Gm-Message-State: AOAM530R7/gikinge/H8/BsrzgsiMmq9XQgE0M4tNMPBw7CS3tFHl9z4 /xHrsJSThKjCho7cLaxg78tTNA== X-Google-Smtp-Source: ABdhPJy7qfGblefp8sNr9ibdBDFyvIk0blXRzO3MeBDTAHyb8i0bLadwNu//+AOg4gqqmwUjNPEHww== X-Received: by 2002:a63:338e:0:b0:398:4302:c503 with SMTP id z136-20020a63338e000000b003984302c503mr12329013pgz.217.1649353469205; Thu, 07 Apr 2022 10:44:29 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id k187-20020a636fc4000000b003983a01b896sm19417131pgc.90.2022.04.07.10.44.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Apr 2022 10:44:28 -0700 (PDT) Date: Thu, 7 Apr 2022 17:44:24 +0000 From: Sean Christopherson To: Vitaly Kuznetsov Cc: kvm@vger.kernel.org, Paolo Bonzini , Wanpeng Li , Jim Mattson , Michael Kelley , Siddharth Chandrasekaran , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 03/31] KVM: x86: hyper-v: Handle HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST{,EX} calls gently Message-ID: References: <20220407155645.940890-1-vkuznets@redhat.com> <20220407155645.940890-4-vkuznets@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220407155645.940890-4-vkuznets@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 07, 2022, Vitaly Kuznetsov wrote: > @@ -1840,15 +1891,47 @@ void kvm_hv_vcpu_flush_tlb(struct kvm_vcpu *vcpu) > { > struct kvm_vcpu_hv_tlbflush_ring *tlb_flush_ring; > struct kvm_vcpu_hv *hv_vcpu = to_hv_vcpu(vcpu); > - > - kvm_vcpu_flush_tlb_guest(vcpu); > - > - if (!hv_vcpu) > + struct kvm_vcpu_hv_tlbflush_entry *entry; > + int read_idx, write_idx; > + u64 address; > + u32 count; > + int i, j; > + > + if (!tdp_enabled || !hv_vcpu) { > + kvm_vcpu_flush_tlb_guest(vcpu); > return; > + } > > tlb_flush_ring = &hv_vcpu->tlb_flush_ring; > + read_idx = READ_ONCE(tlb_flush_ring->read_idx); > + write_idx = READ_ONCE(tlb_flush_ring->write_idx); > + > + /* Pairs with smp_wmb() in hv_tlb_flush_ring_enqueue() */ > + smp_rmb(); > > - tlb_flush_ring->read_idx = tlb_flush_ring->write_idx; > + for (i = read_idx; i != write_idx; i = (i + 1) % KVM_HV_TLB_FLUSH_RING_SIZE) { > + entry = &tlb_flush_ring->entries[i]; > + > + if (entry->flush_all) > + goto out_flush_all; > + > + /* > + * Lower 12 bits of 'address' encode the number of additional > + * pages to flush. > + */ > + address = entry->addr & PAGE_MASK; > + count = (entry->addr & ~PAGE_MASK) + 1; > + for (j = 0; j < count; j++) > + static_call(kvm_x86_flush_tlb_gva)(vcpu, address + j * PAGE_SIZE); > + } > + ++vcpu->stat.tlb_flush; > + goto out_empty_ring; > + > +out_flush_all: > + kvm_vcpu_flush_tlb_guest(vcpu); > + > +out_empty_ring: > + tlb_flush_ring->read_idx = write_idx; Does this need WRITE_ONCE? My usual "I suck at memory ordering" disclaimer applies.