On 9/8/25 07:40, Peter Maydell wrote:
On Sat, 30 Aug 2025 at 16:56, Richard Henderson
<[email protected]> wrote:
These are not architectural state, only placeholders
between identifying the exception and delivering it.
Yes, but is it definitely guaranteed that QEMU will never
do a migration or a record-and-replay record of the cpu
state between identifying the exception and actually
delivering it ?
I note that we do migrate CPUState::exception_index
(added in commit 6c3bff0ed8) which in theory would also
be in this "non architectural state that we consume
immediately" category: so presumably there is some
situation where we might save out the state after
we figure out that we need to raise an exception but
before we call the target's do_interrupt hook.
You're right. In fact, setting this state and jumping back to the main loop is probably
exactly when we'd process the cpu work queue that could trigger the savevm.
Ideally this window would not exist -- we'd process the synchronous exception data
immediately, set the cpu state, and only then jump back to the main loop. But that's a
huge change.
It shouldn't be too hard to adjust this to store 64 bits.
r~
