On 19.05.2022 02:10, Andrew Cooper wrote: > On 17/05/2022 14:21, Roger Pau Monne wrote: >> Under certain conditions guests can get the CPU stuck in an infinite >> loop without the possibility of an interrupt window to occur. > > instruction boundary. > > It's trivial to create an infinite loop without an interrupt window :) > > Also, I'd probably phrase that as an unbounded loop, because not all > problem cases are truly infinite. > >> This >> was the case with the scenarios described in XSA-156. > > Case in point, both of these can be broken by something else (another > vCPU, or coherent DMA write) editing the IDT and e.g. making the #AC/#DB > vectors not present, which will yield #NP instead.
"Can be broken" as in "the loop can be forced to be exited"? If so, how would a remote CPU / agent become aware of the situation, and know what the cause is (and hence know which IDT entry to clobber)? After all it's guest state, which we wouldn't want to alter for no reason. Nor should we put a guest in a state where #DF might eventually result. Jan
