From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51678) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uwl7z-0002BI-A3 for qemu-devel@nongnu.org; Tue, 09 Jul 2013 23:31:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uwl7y-0003DV-AH for qemu-devel@nongnu.org; Tue, 09 Jul 2013 23:31:39 -0400 Message-ID: <1373427084.16720.4.camel@pasglop> From: Benjamin Herrenschmidt Date: Wed, 10 Jul 2013 13:31:24 +1000 In-Reply-To: <20130709151120.GM2696@voom.redhat.com> References: <1372315560-5478-1-git-send-email-aik@ozlabs.ru> <1372315560-5478-5-git-send-email-aik@ozlabs.ru> <874nc429d1.fsf@codemonkey.ws> <51DB9C4B.6080106@ozlabs.ru> <87r4f74yim.fsf@codemonkey.ws> <20130709151120.GM2696@voom.redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 04/17] target-ppc: Convert ppc cpu savevm to VMStateDescription List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: Anthony Liguori , Alexey Kardashevskiy , qemu-devel@nongnu.org, Alexander Graf , Paul Mackerras , Paolo Bonzini , qemu-ppc@nongnu.org On Wed, 2013-07-10 at 01:11 +1000, David Gibson wrote: > More precisely, DCRs are only needed on the BookE CPUs which have > them. They can be added later without breaking compatibility, and > would be best added by someone working on the BookE stuff who can test > it properly. DCRs are also not in the core, they are in the fabric (ie, global chip things) anyway. > Migration will (in fact, does) work without anything extra for the > timebase. What's less clear is if all the timing edge cases are > correct at present. > > As a rule, the guest should see the timebase advance across the > migration according to the elapsed wall clock time. But the guest > *must not* see the timebase go backwards, even if the source and > destination host clocks are out of sync in such a way that time > appears to go backwards across the migration. > > Under TCG, the guest timebase is not tracked as it advances, but an > appropriate value is computed from the host system time when the > timebase is read. Under KVM, the host and guest timebase are the same > register physically. We don't yet, but we probably should, context > switch the upper bits of the timebase, to give the guest its own > logical value for it. > > Getting all the combinations of cases corrects probably needs some > sort of real time <-> guest timebase delta transferred across the > migration, but working out exactly what's needed and how to encode it > is a bit fiddly. > > Since the common cases work already, and it's fairly straightforward > to add whatever delta is needed in a backwards compatible way. It > seems reasonable, therefore to get migration mostly working, even with > some known bugs in timing edge cases. What do you mean by the "common case" ? The common case of KVM does not work afaik. The timebase *will* appear to go backward if the target machine was booted after the source machine today which is likely to crash the kernel. The timebase context switching must be implemented asap. We've discussed it a few times here and we know how to do it, it's just not done yet. Cheers, Ben.