On 2011-12-20 01:53, Anthony Liguori wrote: > 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@xxxxxxxxxxx> >>>>> >>>>> 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. Correct, it's just kept up to date. > > 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? Almost. timer_expiry is calculated on get_apic_state based on the APIC registers. And it is initialized on reset. But it is never saved into the kernel nor does it otherwise affect the in-kernel model. It is really just a compatibility field for potential user space apic usage. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
