On Mon, Jun 28, 2021 at 3:23 PM stsp <stsp2@xxxxxxxxx> wrote: > > 28.06.2021 19:19, Jim Mattson пишет: > > It seems to me that the crux of the problem here is that > > run->ready_for_interrupt_injection returns true when it should return > > false. That's probably where you should focus your efforts. > > OK, it was occasionally found that > it actually worked that way in the > past. This patch: > https://www.lkml.org/lkml/2020/12/1/324 > from Paolo removes the > !kvm_event_needs_reinjection(vcpu) > check. > > Paolo, maybe you can comment? > > > > This isn't CPU-specific. Even when using EPT, you can potentially end > > up in this state after an EPT violation during IDT vectoring. > > Well, in that case you will at > least return the proper status > about the EPT violation. > But for EINTR this is definitely > going to be CPU-specific. No; it's not. After fixing up the EPT violation, when the interrupted IDT vectoring operation is reinjected via the VM-entry interruption-information field, you can still get kicked out of the vcpu run loop by an alarm, and you're in exactly the same boat. > And a rather nasty one: running > a ring3 guest with CPL=0 and IF > always set, and having to check > for ready_to_injection upon EINTR > on just one CPU, is very unexpected. You should *always* be checking ready_for_interrupt_injection before injecting an interrupt, regardless of CPU. That's the API. > So I won't be claiming that Paolo's > patch is incorrect. Maybe someone > can think of the way to just not > get such scenario on EINTR? How long are you willing to defer the EINTR? What if you're running at the target of a live migration, and the guest's IDT page needs to be demand-fetched over the network? It may be quite some time before you can actually deliver that exception.
