From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56606) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wnma7-0006ZN-ST for qemu-devel@nongnu.org; Fri, 23 May 2014 06:20:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WnmZy-0004Gh-As for qemu-devel@nongnu.org; Fri, 23 May 2014 06:20:07 -0400 Received: from mail-qc0-x229.google.com ([2607:f8b0:400d:c01::229]:52998) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WnmZy-0004GW-6H for qemu-devel@nongnu.org; Fri, 23 May 2014 06:19:58 -0400 Received: by mail-qc0-f169.google.com with SMTP id e16so7774319qcx.14 for ; Fri, 23 May 2014 03:19:57 -0700 (PDT) Sender: sendmail Message-ID: <537F20C7.2030107@laine.org> Date: Fri, 23 May 2014 13:19:51 +0300 From: Laine Stump MIME-Version: 1.0 References: <1400756850-19807-1-git-send-email-laine@laine.org> <1400756850-19807-4-git-send-email-laine@laine.org> <537E50FA.1000304@redhat.com> <20140523035038.GA23327@amt.cnet> <537F123F.3030706@laine.org> In-Reply-To: <537F123F.3030706@laine.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [libvirt] [PATCHv2 3/4] qemu: fix RTC_CHANGE event for List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti , Eric Blake Cc: libvir-list@redhat.com, "qemu-devel@nongnu.org" On 05/23/2014 12:17 PM, Laine Stump wrote: > *However*, this discussion forced me to investigate some of the basic > assumptions that I'd been making when coming in to fix this bug. In > particular, my assumption was that the value of "adjustment" that was > set in the status would be preserved across a domain save/restore > operation, or a migration, but after talking to jdenemar and looking > at the code, I believe that this is *not* the case. Okay, disregard this "sky is falling" outburst. I was misreading the code and misinterpreting what jdenemar told me. The updated value of adjustment and basis *are* properly preserved across save/restore and migrate. The problem Eric pointed out is real though (if the domain RTC is modified while libvirtd isn't available to catch the RTC_CHANGE event, libvirt will have an incorrect idea of adjustment. This will be temporary until another RTC_CHANGE event happens *unless* the domain is migrated or saved/restored before another RTC_CHANGE happens, in which case the incorrectness will be semi-permanent (until the domain is completely stopped and restarted).) Also, as I understand it, this means that if a domain is migrated with persistence, the new domain on the destination will have made the change to adjustment and basis permanent, but if it stays on the same host that change will only be valid until the domain is destroyed - next time it is started it will go back to the original settings.