[Top][All Lists]

[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: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH v5 07/16] apic: Open-code timer save/restore
Date: Tue, 20 Dec 2011 01:34:02 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

On 2011-12-20 01:31, Anthony Liguori wrote:
> 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?

Nope. It's kept for eventual use by a user space model.

> 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?

There is nothing broken, at least according to my tests. Migration works
between both backend variants.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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