2018-08-29 09:34-0700, Sean Christopherson: > On Wed, Aug 29, 2018 at 06:18:20PM +0200, Radim Krčmář wrote: > > 2018-08-29 18:43+0300, Liran Alon: > > > Consider the case L1 had a pending event until it executed > > > VMLAUNCH/VMRESUME which wasn't delivered because it was disallowed > > > (e.g. interrupts disabled). When L1 executes VMLAUNCH/VMRESUME, > > > L0 needs to evaluate if this pending event should cause an exit from > > > L2 to L1 or delivered directly to L2 (In case L1 don't intercept > > > EXTERNAL_INTERRUPT). > > > > > > Usually this would be handled by L0 requesting a window (e.g. IRQ > > > window) by setting VMCS accordingly. However, this setting was done on > > > VMCS01 and now VMCS02 is active instead. Thus, when L1 executes > > > VMLAUNCH/VMRESUME we force L0 to perform pending event evaluation by > > > requesting a KVM_REQ_EVENT. > > > > > > Note that above scenario exists when L1 KVM is about to enter L2 but > > > requests an "immediate-exit". As in this case, L1 will > > > disable-interrupts and then send a self-IPI before entering L2. > > > > Which makes it a big blunder, I'll add "Cc: stable@xxxxxxxxxxxxxxx". > > Please hold off on doing anything with this, I don't think this is the > correct fix. I have a half-finished response to the preemption timer > thread that prompted this patch, I'll get that sent ASAP. Sure, thanks for the heads-up.
