Xiaoyao Li <xiaoyao.li@xxxxxxxxx> writes: > On 7/1/2020 5:04 PM, Vitaly Kuznetsov wrote: >> Chenyi Qiang <chenyi.qiang@xxxxxxxxx> 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. Exiting to userspace would allow to implement custom 'throttling' policies to mitigate the 'noisy neighbour' problem. The simplest would be to just inject some sleep time. -- Vitaly
