qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v5 07/16] apic: Open-code timer save/restore


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH v5 07/16] apic: Open-code timer save/restore
Date: Mon, 19 Dec 2011 18:31:35 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15

On 12/19/2011 05:45 PM, Jan Kiszka wrote:
On 2011-12-19 23:21, Anthony Liguori wrote:
On 12/15/2011 06:33 AM, Jan Kiszka wrote:
To enable migration between accelerated and non-accelerated APIC models,
we will need to handle the timer saving and restoring specially and can
no longer rely on the automatics of VMSTATE_TIMER. Specifically,
accelerated model will not start any QEMUTimer.

This patch therefore factors out the generic bits into apic_next_timer
and introduces a post-load callback that can be implemented differently
by both models.

Signed-off-by: Jan Kiszka<address@hidden>

So you basically want the timer to be a dummy field for the in-kernel apic?

Can you fix this up in a pre-save routine (put QEMUTimer into a state
where there isn't an event pending)?

It is not a dummy field, it contains the proper state in both cases. We
just need to convert it to an open-coded state to avoid the QEMUTimer
restoration magic in the in-kernel case (where there must be no QEMUTimer).

So the state gets fed into the kernel instead of userspace?

This seems a bit much to me, can't we just have two VMStateDescriptions that happen to look the same and break migration between userspace and in-kernel?

Are we trying to solve a problem no one cares about?

If you want to avoid regressing migration compat in qemu-kvm, have the vmstate name both be the same, it can be two separate devices as the vmstate name is not tied to the qdev name right now.

Regards,

Anthony Liguori


Jan





reply via email to

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