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 X-Spam-Level: X-Spam-Status: No, score=-16.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DE388C49EA6 for ; Thu, 24 Jun 2021 08:16:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BF508613ED for ; Thu, 24 Jun 2021 08:16:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231899AbhFXISb (ORCPT ); Thu, 24 Jun 2021 04:18:31 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:53738 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231740AbhFXISa (ORCPT ); Thu, 24 Jun 2021 04:18:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1624522570; 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=DKQaOPGFJZZQ5vgX+LfD77sztyavfZnG8AS/L9awIW4=; b=DnRt8Ux1YKZ9RbSALieNRKeSdewlu7k5UWI5+Vf4NXb09ccGJZedysMiQSuO70VP07mUvz qUgkM9wABc+b9v6YhchkAqSYoPPfzYff6YixLJ6iQVYlp/lvjX5VXqmaEARKl3gW+VnEzt uoHLUPqGFxYRQSEhCu7MFIJgLivUKVs= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-77-c72DeYBoNoeA8_C0maJpNw-1; Thu, 24 Jun 2021 04:16:07 -0400 X-MC-Unique: c72DeYBoNoeA8_C0maJpNw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8B637A40C0; Thu, 24 Jun 2021 08:16:05 +0000 (UTC) Received: from starship (unknown [10.40.192.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id 013835D705; Thu, 24 Jun 2021 08:16:01 +0000 (UTC) Message-ID: Subject: Re: [PATCH 07/10] KVM: SVM: use vmcb01 in svm_refresh_apicv_exec_ctrl From: Maxim Levitsky To: Paolo Bonzini , kvm@vger.kernel.org Cc: Thomas Gleixner , Sean Christopherson , Wanpeng Li , Vitaly Kuznetsov , Joerg Roedel , Borislav Petkov , "H. Peter Anvin" , Ingo Molnar , "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Jim Mattson Date: Thu, 24 Jun 2021 11:16:00 +0300 In-Reply-To: References: <20210623113002.111448-1-mlevitsk@redhat.com> <20210623113002.111448-8-mlevitsk@redhat.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2021-06-23 at 23:54 +0200, Paolo Bonzini wrote: > On 23/06/21 13:29, Maxim Levitsky wrote: > > AVIC is not supported for nesting but in some corner > > cases it is possible to have it still be enabled, > > after we entered nesting, and use vmcb02. > > > > Fix this by always using vmcb01 in svm_refresh_apicv_exec_ctrl > > Please be more verbose about the corner case (and then the second > paragraph should not be necessary anymore). I will do it. The issue can happen only after patch 8 is applied, because then AVIC disable on the current vCPU is always deferred. I think that currently the problem in this patch can't happen because kvm_request_apicv_update(..., APICV_INHIBIT_REASON_NESTED) is called on each vCPU from svm_vcpu_after_set_cpuid, and since it disables it on current vCPU, the AVIC is fully disabled on all vCPUs when we get to the first guest entry, even if nested (after a migration the first guest entry can be already nested) After patch 8, the AVIC disable is done at guest entry where we already are in L2, thus we should toggle it in vmcb01, while vmcb02 shouldn't have AVIC enabled in the first place. Best regards, Maxim Levitsky > > Paolo > > > Signed-off-by: Maxim Levitsky > > --- > > arch/x86/kvm/svm/avic.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c > > index 1d01da64c333..a8ad78a2faa1 100644 > > --- a/arch/x86/kvm/svm/avic.c > > +++ b/arch/x86/kvm/svm/avic.c > > @@ -646,7 +646,7 @@ static int svm_set_pi_irte_mode(struct kvm_vcpu *vcpu, bool activate) > > void svm_refresh_apicv_exec_ctrl(struct kvm_vcpu *vcpu) > > { > > struct vcpu_svm *svm = to_svm(vcpu); > > - struct vmcb *vmcb = svm->vmcb; > > + struct vmcb *vmcb = svm->vmcb01.ptr; > > bool activated = kvm_vcpu_apicv_active(vcpu); > > > > if (!enable_apicv) > >