Messages in this thread | | | Subject | Re: [RFC 2/2] KVM: VMX: Enable bus lock VM exit | From | Xiaoyao Li <> | Date | Wed, 1 Jul 2020 17:32:53 +0800 |
| |
On 7/1/2020 5:04 PM, Vitaly Kuznetsov wrote: > Chenyi Qiang <chenyi.qiang@intel.com> writes: [...] >> static const int kvm_vmx_max_exit_handlers = >> @@ -6830,6 +6838,13 @@ static fastpath_t vmx_vcpu_run(struct kvm_vcpu *vcpu) >> if (unlikely(vmx->exit_reason.failed_vmentry)) >> return EXIT_FASTPATH_NONE; >> >> + /* >> + * check the exit_reason to see if there is a bus lock >> + * happened in guest. >> + */ >> + if (vmx->exit_reason.bus_lock_detected) >> + handle_bus_lock(vcpu); > > In case the ultimate goal is to have an exit to userspace on bus lock,
I don't think we will need an exit to userspace on bus lock. See below.
> the two ways to reach handle_bus_lock() are very different: in case > we're handling EXIT_REASON_BUS_LOCK we can easily drop to userspace by > returning 0 but what are we going to do in case of > exit_reason.bus_lock_detected? The 'higher priority VM exit' may require > exit to userspace too. So what's the plan? Maybe we can ignore the case > when we're exiting to userspace for some other reason as this is slow > already and force the exit otherwise?
> And should we actually introduce > the KVM_EXIT_BUS_LOCK and a capability to enable it here? >
Introducing KVM_EXIT_BUS_LOCK maybe help nothing. No matter EXIT_REASON_BUS_LOCK or exit_reason.bus_lock_detected, the bus lock has already happened. Exit to userspace cannot prevent bus lock, so what userspace can do is recording and counting as what this patch does in vcpu->stat.bus_locks.
| |