On Thu, Sep 03, 2020 at 08:52:41AM +0800, Xiaoyao Li wrote:
> On 9/3/2020 6:44 AM, Sean Christopherson wrote:
> > On Tue, Sep 01, 2020 at 10:43:12AM +0200, Vitaly Kuznetsov wrote:
> > > > + vcpu->arch.bus_lock_detected = true;
> > > > + } else {
> > > > + vcpu->arch.bus_lock_detected = false;
> > >
> > > This is a fast path so I'm wondering if we can move bus_lock_detected
> > > clearing somewhere else.
> >
> > Why even snapshot vmx->exit_reason.bus_lock_detected? I don't see any
> > reason why vcpu_enter_guest() needs to handle the exit to userspace, e.g.
> > it's just as easily handled in VMX code.
>
> Because we want to handle the exit to userspace only in one place, i.e.,
> after kvm_x86_ops.handle_exit(vcpu, exit_fastpath). Otherwise, we would have
> to check vmx->exit_reason.bus_lock_detected in every other handler, at least
> in those can preempt the bus lock VM-exit theoretically.
That's not hard to do in vmx.c, e.g.
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 0316b86bad43a..ea2fed7f21565 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -5677,7 +5677,7 @@ void dump_vmcs(void)
* The guest has exited. See if we can fix it or if we need userspace
* assistance.
*/
-static int vmx_handle_exit(struct kvm_vcpu *vcpu, fastpath_t exit_fastpath)
+static int __vmx_handle_exit(struct kvm_vcpu *vcpu, fastpath_t exit_fastpath)
{
struct vcpu_vmx *vmx = to_vmx(vcpu);
u32 exit_reason = vmx->exit_reason;
@@ -5822,6 +5822,22 @@ static int vmx_handle_exit(struct kvm_vcpu *vcpu, fastpath_t exit_fastpath)
return 0;
}
+static int vmx_handle_exit(struct kvm_vcpu *vcpu, fastpath_t exit_fastpath)
+{
+ int ret = __vmx_handle_exit(vcpu, exit_fastpath);
+
+ if (vmx->exit_reason.bus_lock_detected) {
+ if (ret)
+ vcpu->run->exit_reason = KVM_EXIT_BUS_LOCK;
+ else
+ vcpu->run->flags |= KVM_RUN_BUS_LOCK;
+ return 0;
+ }
+
+ vcpu->run->flags &= ~KVM_RUN_BUS_LOCK;
+ return ret;
+}
+
/*
* Software based L1D cache flush which is used when microcode providing
* the cache control MSR is not loaded.
