Avi Kivity wrote: > Jan Kiszka wrote: >> First, this must return 1 (or set an exit reason, but there is no reason >> to escape to user space here). And second, I think a corner case is not >> handled the same way as on real iron: If there is already the next NMI >> waiting, we will inject it before iret, not after its execution as it >> should be. >> > > Yes, good catch. > >> No easy solution for this yet. Maybe emulating iret, but there is no >> implementation, specifically for protected mode. > > That will be a disaster, IRET is horribly complicated.
Yeah, I know... > >> Maybe setting a >> breakpoint. Or maybe enforcing a single step exception. > > Single step looks good, except that it may conflict with a guest > debugging itself (guest debugging an NMI handler?!). But that should be solvable without too much effort. BTW, guest single-stepping in and out of interrupt handlers is not properly working anyway. We only set TF in current eflags but do not bother about the CPU state that will get loaded next. Given some rainy days (or a paying customer) I think I'll look into this once again. Same goes for suppressing IRQ injection while single-stepping just as QEMU does, which may even come earlier as someone already asked for it. > >> Nothing trivial >> in this list. On the other hand, this may only be a slight imprecision >> of the virtualization. Need to think about it. >> > > It may cause a stack overflow if we have a huge stream of NMIs (if an > NMI triggers an NMI in the handler). Of course that's a totally > unrealistic scenario. > Good point. But as it is a corner case, I think we can fly without a complete solution first, fixing it in a second step. Jan
signature.asc
Description: OpenPGP digital signature
