These are not architectural state, only placeholders
between identifying the exception and delivering it.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
---
 target/arm/machine.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/target/arm/machine.c b/target/arm/machine.c
index 6986915bee..8dbeca2867 100644
--- a/target/arm/machine.c
+++ b/target/arm/machine.c
@@ -1085,9 +1085,9 @@ const VMStateDescription vmstate_arm_cpu = {
         VMSTATE_UINT64(env.exclusive_val, ARMCPU),
         VMSTATE_UINT64(env.exclusive_high, ARMCPU),
         VMSTATE_UNUSED(sizeof(uint64_t)),
-        VMSTATE_UINT32(env.exception.syndrome, ARMCPU),
-        VMSTATE_UINT32(env.exception.fsr, ARMCPU),
-        VMSTATE_UINT64(env.exception.vaddress, ARMCPU),
+        VMSTATE_UNUSED(sizeof(uint32_t)),
+        VMSTATE_UNUSED(sizeof(uint32_t)),
+        VMSTATE_UNUSED(sizeof(uint64_t)),
         VMSTATE_TIMER_PTR(gt_timer[GTIMER_PHYS], ARMCPU),
         VMSTATE_TIMER_PTR(gt_timer[GTIMER_VIRT], ARMCPU),
         {
-- 
2.43.0

On Sat, 30 Aug 2025 at 16:56, Richard Henderson
<richard.henderson@linaro.org> 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.

-- PMM

On 9/8/25 07:40, Peter Maydell wrote:
> On Sat, 30 Aug 2025 at 16:56, Richard Henderson
> <richard.henderson@linaro.org> 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~