Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3911516pxv; Mon, 26 Jul 2021 15:37:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzsUYwxcCaBuzQpAX0JLYRL6pdGV6G0I+889rdNZQMsF3S0m9b/hxbCJj9k5fbqKpREB0Es X-Received: by 2002:a92:cf48:: with SMTP id c8mr14617568ilr.237.1627339027721; Mon, 26 Jul 2021 15:37:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627339027; cv=none; d=google.com; s=arc-20160816; b=IYjUmA0JSRbk9XLqc+Q43vR2dVU4rJ+oPradxNwVJJbA5j5KJxpmafOFEzi6YC5FJ7 RfOxeTbibKi3PL22w8JlnsujEwlRDL5vblxePa4ul2wqtX0IEVMBAA1iIoibYLdpJUqS N2zSCxkQhvbw76u4xEI2BTTUQNINrtgzCSn7OzoNzUfGas5XeI/1HkmApVsCDzE6s3/N lYQ6aj31q1w7BcoaDAJYulkfPv33syLMez47cmFFXRRQM+bAYXKQdqMTuCt7kCYMdrXK awlqVIqcdT4I4LvCKMINnuWU9Zq8IoDi9xF1S/sv1ouhnzcW/gJEpUckFrSnOhF5eWlI RWHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:subject:from :references:cc:to:dkim-signature; bh=pgpmDMm0CnqdpOlFLaXq6nbjjRIJeH3bENX23ACSG+U=; b=jHJxYKTQslNOiRawoaeo0N4GHG3RRT4w0lEJw17tOCIh2Sg9Jad6ZG14fPJIn1HXYY 1gIU41/m25Ce/0pruCK96SMGyeL8yjWof+93B27EXV4HazIiiemGHrCDvA+hIAm5G0Em 8ttWeNCuIvVqRTaSn1pfKsnHci1PorttifICoOxi7L+5bTp8BLhaVC9GV3BYXLQDF1Qo vqSWSyVZ5P/LWtAL2WB1rae2t25t/A/zy0Vh/a95iH9ZMOpIbN36EvHFfq2n3S5veFpv iFAxSYAuVo/ft/LI1eOO/022ZVuXH7jJJQDmCBnClmqtsGcorBLHK6LGvPA2ZCbbKb0N VCbA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Y581NGOA; 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 z10si1441259ioq.37.2021.07.26.15.36.55; Mon, 26 Jul 2021 15:37:07 -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=Y581NGOA; 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 S233775AbhGZVyg (ORCPT + 99 others); Mon, 26 Jul 2021 17:54:36 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:25765 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233660AbhGZVyf (ORCPT ); Mon, 26 Jul 2021 17:54:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1627338903; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pgpmDMm0CnqdpOlFLaXq6nbjjRIJeH3bENX23ACSG+U=; b=Y581NGOAvOn/0E06XH/cEOUqMXS10ZPP5HiYyu/mqIXAKXnh/Jrn80BjTWY7cGSERHjhn+ EY0Tbn9y3AqqFBdufkNJ94AmZ/jNA0KJK5IsaHRsmxohtpoOEw+Jn5ctjavKUXfdSG4nP8 hJIvuC/zOg3JoPk37UGIZ/ILk691Zps= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-49-lbm1CTsCMiGZRaqOeXZQMA-1; Mon, 26 Jul 2021 18:35:01 -0400 X-MC-Unique: lbm1CTsCMiGZRaqOeXZQMA-1 Received: by mail-ej1-f69.google.com with SMTP id qf6-20020a1709077f06b029057e66b6665aso1553366ejc.18 for ; Mon, 26 Jul 2021 15:35:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pgpmDMm0CnqdpOlFLaXq6nbjjRIJeH3bENX23ACSG+U=; b=sVrkpJVlAwLZOxpMrYYOWSFBnvbPj5B7HDMieBjEt6yEIXVc6PrT+5r4/UxX/NYCND /oQ360haaRj9d4MheVNeN38M5RrsD4KpksBph5wUEcxiY+bZimKbOW1NbrZ4tdeuI1MM 5BdnVT+Jh069ICM2paVeIfe7W7/IfDux6x/x0wxED0fvtwUazJTn2Xg5kkCtKP0PY7sj 4IzptXr+k1Ww75WmUYgo6Hu1xvuNfTk3dK5cOAPRD9GSFznU8QsgnLqv9x4vbs+14iy6 hTiOnCiwwRvg/V1DWLf9ngd3i4pXq8+uPPvpwTRhfqs8dL/xJeDbpUAi68tlBpO8o8q6 Mo5g== X-Gm-Message-State: AOAM533EvPgMhrhrB9ZowxHywXy/q5h63hZhbZdkwopsaNDjoxxJu6x2 symRneJjM7dCmQY73zcfFT+tHKSEA/JJ1KRUSIuaHC1EqNsLbSxaZeYb1VycrK2R0+/Uu22fUmd KDbjTWUxlQ0iL0HAYgMeqpTCA X-Received: by 2002:a05:6402:274f:: with SMTP id z15mr9980871edd.21.1627338900490; Mon, 26 Jul 2021 15:35:00 -0700 (PDT) X-Received: by 2002:a05:6402:274f:: with SMTP id z15mr9980858edd.21.1627338900296; Mon, 26 Jul 2021 15:35:00 -0700 (PDT) Received: from ?IPv6:2001:b07:6468:f312:63a7:c72e:ea0e:6045? ([2001:b07:6468:f312:63a7:c72e:ea0e:6045]) by smtp.gmail.com with ESMTPSA id jy17sm281162ejc.112.2021.07.26.15.34.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jul 2021 15:34:59 -0700 (PDT) To: Maxim Levitsky , kvm@vger.kernel.org Cc: "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Jim Mattson , Joerg Roedel , Borislav Petkov , Vitaly Kuznetsov , Wanpeng Li , Thomas Gleixner , "H. Peter Anvin" , Ingo Molnar , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Sean Christopherson References: <20210713142023.106183-1-mlevitsk@redhat.com> <20210713142023.106183-6-mlevitsk@redhat.com> From: Paolo Bonzini Subject: Re: [PATCH v2 5/8] KVM: x86: APICv: fix race in kvm_request_apicv_update on SVM Message-ID: Date: Tue, 27 Jul 2021 00:34:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210713142023.106183-6-mlevitsk@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13/07/21 16:20, Maxim Levitsky wrote: > + mutex_lock(&vcpu->kvm->apicv_update_lock); > + > vcpu->arch.apicv_active = kvm_apicv_activated(vcpu->kvm); > kvm_apic_update_apicv(vcpu); > static_call(kvm_x86_refresh_apicv_exec_ctrl)(vcpu); > @@ -9246,6 +9248,8 @@ void kvm_vcpu_update_apicv(struct kvm_vcpu *vcpu) > */ > if (!vcpu->arch.apicv_active) > kvm_make_request(KVM_REQ_EVENT, vcpu); > + > + mutex_unlock(&vcpu->kvm->apicv_update_lock); Does this whole piece of code need the lock/unlock? Does it work and/or make sense to do the unlock immediately after mutex_lock()? This makes it clearer that the mutex is being to synchronize against the requestor. > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > index ed4d1581d502..ba5d5d9ebc64 100644 > --- a/virt/kvm/kvm_main.c > +++ b/virt/kvm/kvm_main.c > @@ -943,6 +943,7 @@ static struct kvm *kvm_create_vm(unsigned long type) > mutex_init(&kvm->irq_lock); > mutex_init(&kvm->slots_lock); > mutex_init(&kvm->slots_arch_lock); > + mutex_init(&kvm->apicv_update_lock); > INIT_LIST_HEAD(&kvm->devices); > > BUILD_BUG_ON(KVM_MEM_SLOTS_NUM > SHRT_MAX); > Please add comments above fields that are protected by this lock (anything but apicv_inhibit_reasons?), and especially move it to kvm->arch. Paolo