On Wed, Jan 12, 2022, Paolo Bonzini wrote: > On 1/12/22 18:30, Sean Christopherson wrote: > > > Uhhmm, why not? Who says the vcpu will run the moment it becomes > > > runnable again? Another task could be woken up meanwhile occupying the > > > real cpu. > > Hrm, but when emulating HLT, e.g. for an idling vCPU, KVM will voluntarily schedule > > out the vCPU and mark it as preempted from the guest's perspective. The vast majority, > > probably all, usage of steal_time.preempted expects it to truly mean "preempted" as > > opposed to "not running". > > I'm not sure about that. In particular, PV TLB shootdown benefits from > treating a halted vCPU as preempted, because it avoids wakeups of the halted > vCPUs. Ah, right. But that really should be decoupled from steal_time.preempted. KVM can technically handle the PV TLB flush any time the vCPU exits, it's just a question of whether the cost of writing guest memory outweighs the benefits of potentially avoiding an IPI. E.g. modifying KVM's fastpath exit loop to toggle a flag and potentially handle PV TLB flushes is probably a bad idea, but setting a flag immediately before static_call(kvm_x86_handle_exit)() may be a net win.
