From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33020) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYndV-0005Hc-2F for qemu-devel@nongnu.org; Wed, 24 Feb 2016 23:34:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aYndU-0000Kq-2Q for qemu-devel@nongnu.org; Wed, 24 Feb 2016 23:34:45 -0500 References: <20160112024421.GH22925@voom.redhat.com> <56993062.4030604@ilande.co.uk> <20160118045113.GL9301@voom.fritz.box> <56A5B712.9070808@ilande.co.uk> <20160125111008.GG32205@voom.redhat.com> <56A7F3B7.3080908@ilande.co.uk> <20160201005218.GY23043@voom.redhat.com> <56B13EB4.9000309@ilande.co.uk> <20160203045926.GH15080@voom.fritz.box> <56CCCEAD.70805@ilande.co.uk> <20160224004738.GC2808@voom.fritz.box> <87mvqql27q.fsf@emacs.mitica> From: Mark Cave-Ayland Message-ID: <56CE8436.6010404@ilande.co.uk> Date: Thu, 25 Feb 2016 04:33:58 +0000 MIME-Version: 1.0 In-Reply-To: <87mvqql27q.fsf@emacs.mitica> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Migrating decrementer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: quintela@redhat.com, David Gibson Cc: Alexey Kardashevskiy , amit.shah@redhat.com, qemu-ppc@nongnu.org, agraf@suse.de, qemu-devel@nongnu.org On 24/02/16 12:31, Juan Quintela wrote: >> I don't really understand the question. Migration has no equivalent >> in real hardware, so there's no "real" behaviour to mimic. If we >> freeze the TB during migration, then the guest's clock will get out of >> sync with wall clock time, and in a production environment that's >> really bad. So no, we absolutely must not freeze the TB during >> migration. >> >> When the guest has been explicitly paused, there's a case to be made >> either way. > > If this is the case, can't we just change the device to just read the > clock from the host at device insntantiation and call it a day? > > (* Notice that I haven't seen the previous discussion *) > > On migration, having a post-load function that just loads the right > value for that device should work. Or if we want to make it work for > pause/cont, we should have a notifier to be run each time "cont" is > issued, and put a callback there? > > Or I am missing something improtant? Right, that's roughly the approach I was thinking when I wrote my last reply - for KVM derive the timebase from the virtual clock similar to TCG and adjust on CPU start, e.g. cpu_reset(): cpu->tb_env->tb_offset = 0; cpu_start/resume(): cpu->tb_env->tb_offset = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) * tb_env->tb_freq + cpu->tb_env->tb_offset - qemu_clock_get_ns(QEMU_CLOCK_HOST) Is there any reason why this shouldn't work? My understanding is that guests supporting KVM_REG_PPC_TB_OFFSET should compensate correctly for the timebase if tb_offset is the difference from the host timebase at guest virtual time zero. ATB, Mark.