On 09/10/21 04:12, Sean Christopherson wrote:
+ /*
+ * The smp_wmb() in kvm_make_request() pairs with the smp_mb_*()
+ * after setting vcpu->mode in vcpu_enter_guest(), thus the vCPU
+ * is guaranteed to see the event request if triggering a posted
+ * interrupt "fails" because vcpu->mode != IN_GUEST_MODE.
This explanation doesn't make much sense to me. This is just the usual
request/kick pattern explained in
Documentation/virt/kvm/vcpu-requests.rst; except that we don't bother
with a "kick" out of guest mode because the entry always goes through
kvm_check_request (in the nVMX case) or sync_pir_to_irr (if non-nested)
and completes the delivery itself.
In other word, it is a similar idea as patch 43/43.
What this smp_wmb() pair with, is the smp_mb__after_atomic in
kvm_check_request(KVM_REQ_EVENT, vcpu). Setting the interrupt in the
PIR orders before kvm_make_request in this thread, and orders after
kvm_make_request in the vCPU thread.
Here, instead:
+ /*
+ * The implied barrier in pi_test_and_set_on() pairs with the smp_mb_*()
+ * after setting vcpu->mode in vcpu_enter_guest(), thus the vCPU is
+ * guaranteed to see PID.ON=1 and sync the PIR to IRR if triggering a
+ * posted interrupt "fails" because vcpu->mode != IN_GUEST_MODE.
+ */
if (vcpu != kvm_get_running_vcpu() &&
!kvm_vcpu_trigger_posted_interrupt(vcpu, false))
- kvm_vcpu_kick(vcpu);
+ kvm_vcpu_wake_up(vcpu);
it pairs with the smp_mb__after_atomic in vmx_sync_pir_to_irr(). As
explained again in vcpu-requests.rst, the ON bit has the same function
as vcpu->request in the previous case.
Paolo
+ */
kvm_make_request(KVM_REQ_EVENT, vcpu);
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
