From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47259 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q9HPI-00068u-Eo for qemu-devel@nongnu.org; Mon, 11 Apr 2011 09:43:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q9HP5-0004vu-ML for qemu-devel@nongnu.org; Mon, 11 Apr 2011 09:43:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2058) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9HP5-0004vq-Ah for qemu-devel@nongnu.org; Mon, 11 Apr 2011 09:43:43 -0400 Message-ID: <4DA3058A.6070008@redhat.com> Date: Mon, 11 Apr 2011 16:43:38 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH v2 3/5] hpet 'driftfix': add fields to HPETTimer and VMStateDescription References: <148574451.12234.1302512788577.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <4DA2C4F2.1000002@redhat.com> <4DA2FDA8.9070109@us.ibm.com> <1302529181.3021.13.camel@mothafucka.localdomain> In-Reply-To: <1302529181.3021.13.camel@mothafucka.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Glauber Costa Cc: Anthony Liguori , kvm@vger.kernel.org, qemu-devel@nongnu.org, jan kiszka , Ulrich Obergfell , gcosta@redhat.com On 04/11/2011 04:39 PM, Glauber Costa wrote: > On Mon, 2011-04-11 at 08:10 -0500, Anthony Liguori wrote: > > On 04/11/2011 04:08 AM, Avi Kivity wrote: > > > On 04/11/2011 12:06 PM, Ulrich Obergfell wrote: > > >> >> vmstate_hpet_timer = { > > >> >> VMSTATE_UINT64(fsb, HPETTimer), > > >> >> VMSTATE_UINT64(period, HPETTimer), > > >> >> VMSTATE_UINT8(wrap_flag, HPETTimer), > > >> >> + VMSTATE_UINT64_V(saved_period, HPETTimer, 3), > > >> >> + VMSTATE_UINT64_V(ticks_not_accounted, HPETTimer, 3), > > >> >> + VMSTATE_UINT32_V(irqs_to_inject, HPETTimer, 3), > > >> >> + VMSTATE_UINT32_V(irq_rate, HPETTimer, 3), > > >> >> + VMSTATE_UINT32_V(divisor, HPETTimer, 3), > > >> > > > >> > We ought to be able to use a subsection keyed off of whether any > > >> ticks > > >> > are currently accumulated, no? > > >> > > >> > > >> Anthony, > > >> > > >> I'm not sure if I understand your question correctly. Are you suggesting > > >> to migrate the driftfix-related state conditionally / only if there are > > >> any ticks accumulated in 'ticks_not_accounted' and 'irqs_to_inject' ? > > >> > > >> The size of the driftfix-related state is 28 bytes per timer and we have > > >> 32 timers per HPETState, i.e. 896 additional bytes per HPETState. With a > > >> maximum number of 8 HPET blocks (HPETState), this amounts to 7168 bytes. > > >> Hence, unconditional migration of the driftfix-related state should not > > >> cause significant additional overhead. > > >> > > > > > > It's not about overhead. > > > > > >> Maybe I missed something. Could you please explain which benefit you see > > >> in using a subsection ? > > > > > > In the common case of there being no drift, you can migrate from a > > > qemu that supports driftfix to a qemu that doesn't. > > > > > > > Right, subsections are a trick. The idea is that when you introduce new > > state for a device model that is not always going to be set, when you do > > the migration, you detect whether the state is set or not and if it's > > not set, instead of sending empty versions of that state (i.e. > > missed_ticks=0) you just don't send the new state at all. > > > > This means that you can migrate to an older version of QEMU provided the > > migration would work correctly. > > Using subsections and testing for hpet option being disabled vs enabled, > is fine. But checking for the existence of drift, like you suggested (or > at least how I understood you), is very tricky. It is expected to change > many times during guest lifetime, and would make our migration > predictability something Heisenberg would be proud of. First, I'd expect no drift under normal circumstances, at least without overcommit. We may also allow a small amount of drift to pass migration (we lost time during the last phase anyway). Second, the problem only occurs on new->old migrations. -- error compiling committee.c: too many arguments to function