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. > > 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. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
