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

[Anthony Liguori <anthony@codemonkey.ws>]

On 12/19/2011 06:34 PM, Jan Kiszka wrote:
> 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<jan.kiszka@siemens.com>
>>>>
>>>> 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.

I think you misunderstood my comments.

When you are using the in-kernel APIC, the is no implementation for the 
post_load hook.  As far as I can tell, the state isn't used.

I know it's used by the user space model but from what I can tell, the value is 
essentially sync with the in-kernel APIC almost immediately as it happens during 
KVM_RUN.

So it's a QEMUTimer in the userspace model, but it's just an integer when used 
in the in-kernel APIC as the timer never fires.  It is just saved/restored from 
and to the kernel.

Is this correct?

Regards,

Anthony Liguori