On 02/01/18 13:52, Quan Xu wrote:
On 2018年01月02日 19:21, Quan Xu wrote:
yes,
the key point is what does 'a new L1 injectable interrupt' mean..
in your patch, __IIUC__ one of condition to exit guest mode:
1) max_irr_updated - 'vector of PIR' > 'vectors of previous IRR'
as the SDM algorithm said, even if:
'vector of PIR' < 'vectors of previos IRR'
If we has synced PIR to L1's APIC IRR, the 'vector of PIR' _may_ be
delivered to VM..
If we has synced PIR to L1's APIC IRR, the 'vector of PIR' _may_ be
delivered to VM before next VMExit..
it is a new injectable interrupt as well..
Quan
Alibaba Cloud
In case APICv is active (relevant to our case), __apic_accept_irq()
handles APIC_DM_FIXED by calling deliver_posted_interrupt() which will
set a bit in PIR instead of setting a bit in LAPIC IRR.
Therefore, in case APICv is active, the bits that are set in LAPIC IRR
are bits which were synced from PIR to IRR by some previous call of
vmx_sync_pir_to_irr(). (Not considering the case of some user-mode API
setting them manually).
Therefore, the only new injectable interrupts we can encounter in
vmx_sync_pir_to_irr() are vectors coming from the PIR.
It is also not possible for the guest to block interrupt vector X while
still being able to accept vector Y if Y<X. Therefore, it is enough to
just check if max vector from PIR > max vector from IRR before the sync.
It is true that VID will inject the vector in RVI to the guest if
possible on VMEntry. RVI is set by vmx_sync_pir_to_irr() to either the
max value from PIR or the max value from IRR. If the max value from IRR
> max value from PIR, then the vector to be injected to guest was
already evaluated if it should exit to L1 by check_nested_events() and
therefore we don't need to call kvm_vcpu_exiting_guest_mode() again.
Regards,
-Liran
