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;
Subject: Re: [PATCH v3] KVM: LAPIC: Recalculate apic map in batch
To:     Igor Mammedov <imammedo@redhat.com>
Cc:     Wanpeng Li <kernellwp@gmail.com>, linux-kernel@vger.kernel.org,
        kvm@vger.kernel.org,
        Sean Christopherson <sean.j.christopherson@intel.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Jim Mattson <jmattson@google.com>,
        Joerg Roedel <joro@8bytes.org>
References: <1582684862-10880-1-git-send-email-wanpengli@tencent.com>
 <20200619143626.1b326566@redhat.com>
 <3e025538-297b-74e5-f1b1-2193b614978b@redhat.com>
 <20200622002637.33358827@redhat.com>
From:   Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <cc8b429e-74dd-70f1-8f1c-8893a5485e76@redhat.com>
Date:   Mon, 22 Jun 2020 16:37:06 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200622002637.33358827@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 22/06/20 00:26, Igor Mammedov wrote:
> 
> following sequence looks like a race that can cause lost map update events:
> 
>          cpu1                            cpu2
>                              
>                                 apic_map_dirty = true     
>   ------------------------------------------------------------   
>                                 kvm_recalculate_apic_map:
>                                      pass check
>                                          mutex_lock(&kvm->arch.apic_map_lock);
>                                          if (!kvm->arch.apic_map_dirty)
>                                      and in process of updating map
>   -------------------------------------------------------------
>     other calls to
>        apic_map_dirty = true         might be too late for affected cpu
>   -------------------------------------------------------------
>                                      apic_map_dirty = false
>   -------------------------------------------------------------
>     kvm_recalculate_apic_map:
>     bail out on
>       if (!kvm->arch.apic_map_dirty)

I will post a fix for that.  Thanks for the analysis!

Paolo