qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC v1 34/38] target/arm: cpu: only initialize TCG gt timers under


From: Paolo Bonzini
Subject: Re: [RFC v1 34/38] target/arm: cpu: only initialize TCG gt timers under CONFIG_TCG
Date: Tue, 23 Feb 2021 15:47:13 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0

On 23/02/21 12:01, Alex Bennée wrote:
diff --git a/target/arm/machine.c b/target/arm/machine.c
index 666ef329ef..13d7c6d930 100644
--- a/target/arm/machine.c
+++ b/target/arm/machine.c
@@ -822,8 +822,13 @@ const VMStateDescription vmstate_arm_cpu = {
          VMSTATE_UINT32(env.exception.syndrome, ARMCPU),
          VMSTATE_UINT32(env.exception.fsr, ARMCPU),
          VMSTATE_UINT64(env.exception.vaddress, ARMCPU),
+#ifdef CONFIG_TCG
          VMSTATE_TIMER_PTR(gt_timer[GTIMER_PHYS], ARMCPU),
          VMSTATE_TIMER_PTR(gt_timer[GTIMER_VIRT], ARMCPU),
+#else
+        VMSTATE_UNUSED(sizeof(QEMUTimer *)),
+        VMSTATE_UNUSED(sizeof(QEMUTimer *)),
+#endif /* CONFIG_TCG */
I'm not sure this is correct - VMSTATE_TIMER_PTR chases the links to
just expose expired time but QEMUTimer has more in it than that. Paolo

If the timer is never set, it is completely free to create it with timer_new. So it seems simpler to do nothing here.

The observation about the null pointer makes sense, but I think it would break existing migration streams. Also we would like to convert all QEMUTimer* to embedded QEMUTimers, so my advice is to not bother adding it, instead of figuring out how to solve those problems.

Paolo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]