From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] xen: fix initialization of wallclock time for PVHVM on migration Date: Tue, 11 Jun 2013 16:50:38 +0100 Message-ID: References: <51B7283F.4020602@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <51B7283F.4020602@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Roger Pau =?ISO-8859-1?B?TW9ubuk=?= , Jan Beulich Cc: George Dunlap , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 11/06/2013 14:38, "Roger Pau Monn=E9" wrote: > On 11/06/13 13:59, Jan Beulich wrote: >>>>> On 11.06.13 at 12:46, Roger Pau Monne wrote: >>> The initial values of the wallclock time in the shared info page are >>> set for PVHVM guests when the hypercall page is initialized, since the >>> hypercall page is not reinitialized on resume, the hypervisor >>> wallclock time is not properly set on resume. >>> = >>> Fix it by forcing an update of the wallclock values when the shared >>> info page is mapped. >> = >> NACK - this is a guest side bug. After migration, a guest _has_ to >> re-init the hypercall page, as it may have got migrated between >> a VMX and an SVM machine, and the hypercall instructions are >> different between them. > = > I've re-inited the hypercall page on resume, but the hypervisor > wallclock is still 0. > = > The call to update_domain_wallclock_time in hvm_latch_shinfo_size is > gated, and doesn't get called on the resume path. Would it be OK to call > update_domain_wallclock_time unconditionally on > hvm_hypercall_page_initialise? Yes, just posted to confirm this is probably a good fix. By the by, we also latch_shinfo_size() on setup of HVM_PARAM_CALLBACK_IRQ, and you surely do *that* on PVHVM resume already. So although also re-initialising the hypercall page is also a good idea on the resume path, even guests without that fix should benefit from making the call in latch_shinfo_size() unconditional. -- Keir