linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Xiaoyao Li <xiaoyao.li@intel.com>
To: Sean Christopherson <seanjc@google.com>,
	Chenyi Qiang <chenyi.qiang@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: nVMX: Fix nested bus lock VM exit
Date: Thu, 2 Sep 2021 09:32:07 +0800	[thread overview]
Message-ID: <0f064b93-8375-8cba-6422-ff12f95af656@intel.com> (raw)
In-Reply-To: <YS/BrirERUK4uDaI@google.com>

On 9/2/2021 2:08 AM, Sean Christopherson wrote:
> On Fri, Aug 27, 2021, Chenyi Qiang wrote:
>> Nested bus lock VM exits are not supported yet. If L2 triggers bus lock
>> VM exit, it will be directed to L1 VMM, which would cause unexpected
>> behavior. Therefore, handle L2's bus lock VM exits in L0 directly.
>>
>> Fixes: fe6b6bc802b4 ("KVM: VMX: Enable bus lock VM exit")
>> Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com>
>> ---
>>   arch/x86/kvm/vmx/nested.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
>> index bc6327950657..754f53cf0f7a 100644
>> --- a/arch/x86/kvm/vmx/nested.c
>> +++ b/arch/x86/kvm/vmx/nested.c
>> @@ -5873,6 +5873,8 @@ static bool nested_vmx_l0_wants_exit(struct kvm_vcpu *vcpu,
>>   	case EXIT_REASON_VMFUNC:
>>   		/* VM functions are emulated through L2->L0 vmexits. */
>>   		return true;
>> +	case EXIT_REASON_BUS_LOCK:
>> +		return true;
> 
> Hmm, unless there is zero chance of ever exposing BUS_LOCK_DETECTION to L1, it
> might be better to handle this in nested_vmx_l1_wants_exit(), e.g.
> 
> diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
> index b3f77d18eb5a..793534b7eaba 100644
> --- a/arch/x86/kvm/vmx/nested.c
> +++ b/arch/x86/kvm/vmx/nested.c
> @@ -6024,6 +6024,8 @@ static bool nested_vmx_l1_wants_exit(struct kvm_vcpu *vcpu,
>                          SECONDARY_EXEC_ENABLE_USR_WAIT_PAUSE);
>          case EXIT_REASON_ENCLS:
>                  return nested_vmx_exit_handled_encls(vcpu, vmcs12);
> +       case EXIT_REASON_BUS_LOCK:
> +               return nested_cpu_has2(vmcs12, SECONDARY_EXEC_BUS_LOCK_DETECTION);

yes, for now, it equals

                   return false;

because KVM doesn't expose it to L1.

>          default:
>                  return true;
>          }
> 
> It's a rather roundabout way of reaching the same result, but I'd prefer to limit
> nested_vmx_l0_wants_exit() to cases where L0 wants to handle the exit regardless
> of what L1 wants.  This kinda fits that model, but it's not really that L0 "wants"
> the exit, it's that L1 can't want the exit.  Does that make sense?

something like below has to be in nested_vmx_l0_wants_exit()

--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -5873,6 +5873,8 @@ static bool nested_vmx_l0_wants_exit(struct 
kvm_vcpu *vcpu,
         case EXIT_REASON_VMFUNC:
                 /* VM functions are emulated through L2->L0 vmexits. */
                 return true;
+       case EXIT_REASON_BUS_LOCK:
+               return vcpu->kvm->arch.bus_lock_detection_enabled;
         default:
                 break;
         }


L0 wants this VM exit because it enables BUS LOCK VM exit, not because 
L1 doesn't enable it.

> 
>>   	default:
>>   		break;
>>   	}
>> -- 
>> 2.17.1
>>


  reply	other threads:[~2021-09-02  1:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-27  8:51 [PATCH] KVM: nVMX: Fix nested bus lock VM exit Chenyi Qiang
2021-08-27 11:13 ` Xiaoyao Li
2021-09-01 18:08 ` Sean Christopherson
2021-09-02  1:32   ` Xiaoyao Li [this message]
2021-09-09 17:59     ` Sean Christopherson
2021-09-10  1:46       ` Xiaoyao Li
2021-09-10 15:19         ` Sean Christopherson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0f064b93-8375-8cba-6422-ff12f95af656@intel.com \
    --to=xiaoyao.li@intel.com \
    --cc=chenyi.qiang@intel.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).