On 10/11/17 23:37, Paolo Bonzini wrote:
On 10/11/2017 19:06, Radim Krčmář wrote:
/* the PIR and ON have been set by L1. */
if (!kvm_vcpu_trigger_posted_interrupt(vcpu, true)) {
This would still fail on the exiting case.
If one VCPU was just after a VM exit, then the sender would see it
IN_GUEST_MODE, send the posted notification and return true, but the
notification would do nothing
It would cause *something*---a vmexit because the vector doesn't match
the L1 posted interrupt. Then smp_kvm_posted_intr_nested_ipi would be
invoked from vmx_handle_external_intr.
Could we detect the vector in vmx_handle_external_intr and set
pi_pending+KVM_REQ_EVENT? Or invoke a function in KVM from
smp_kvm_posted_intr_nested_ipi? Or would both be insane?...
I have actually thought about it before writing this patch. But have
found an issue with this approach (which doesn't exist in this v1 patch
and in Radim's suggestion for v2):
Consider the case sender sees vcpu->mode==IN_GUEST_MODE and before it
sends the physical IPI, dest CPU exits from guest and continues in L0
all the way until vcpu_enter_guest() and pass the part it checks for
KVM_REQ_EVENT but before it disables interrupts. Then sender sends the
physical IPI which is received in host-context and therefore runs
smp_kvm_posted_intr_nested_ipi() which sets KVM_REQ_EVENT &
pi_pending=true. But without Radim's suggestion of checking pi_pending
after interrupts disabled, this is too late as dest CPU will not check
these again until next exit from L2 guest.
I hope I didn't misunderstand something here :)
Thanks,
Paolo
and we didn't set vmx->nested.pi_pending =
true, so the interrupt would not get handled until the next posted
notification or nested VM entry.
