28.06.2021 19:19, Jim Mattson пишет:
This doesn't work. Kvm has no facilities for converting an injected exception back into a pending exception.
What is the purpose of the cancel_injection then?
In particular, if the exception has side effects, such as a #PF which sets CR2, those side effects have already taken place. Once kvm sets the VM-entry interruption-information field, the next VM-entry must deliver that exception. You could arrange to back it out, but you would also have to back out the changes to CR2 (for #PF) or DR6 (for #DB). Cancel_injection *should* leave the exception in the 'injected' state,
But it removes it from VMCS, no? I thought "injected=true" means "injected to VMCS". What is the difference between "injected" and "pending" if both may or may not mean "already in VMCS"?
and KVM_SET_REGS *should not* clear an injected exception. (I don't think it's right to clear a pending exception either, if that exception happens to be a trap, but that's a different discussion). 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.
I tried that already, and showed the results to you. :) Alas, you didn't reply to those. But why do you suggest the cpu-specific approach? All other CPUs exit to user-space only when the exception is _really_ injected, i.e. CS/EIP points to the IDT handler. I don't see why it should be non-atomic just for one CPU. Shouldn't that be atomic for all CPUs?
