From mboxrd@z Thu Jan 1 00:00:00 1970 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 Message-ID: <4EEFD767.2050703@codemonkey.ws> References: <61e59db37279bb3834b996c84e9a0523638f5e35.1323952403.git.jan.kiszka@siemens.com> <4EEFB8FB.3030105@codemonkey.ws> <4EEFCC92.9030300@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, "Michael S. Tsirkin" , Marcelo Tosatti , qemu-devel , Blue Swirl , Avi Kivity To: Jan Kiszka Return-path: Received: from mail-gy0-f174.google.com ([209.85.160.174]:63224 "EHLO mail-gy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753635Ab1LTAbi (ORCPT ); Mon, 19 Dec 2011 19:31:38 -0500 Received: by ghbz12 with SMTP id z12so3866289ghb.19 for ; Mon, 19 Dec 2011 16:31:37 -0800 (PST) In-Reply-To: <4EEFCC92.9030300@web.de> Sender: kvm-owner@vger.kernel.org List-ID: 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 >> >> 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 >