Re: [Xen-devel] [PATCH] xen: fix initialization of wallclock time for PVHVM on migration

[Keir Fraser <keir.xen@xxxxxxxxx>]

On 11/06/2013 14:38, "Roger Pau Monné" <roger.pau@xxxxxxxxxx> wrote:

> On 11/06/13 13:59, Jan Beulich wrote:
>>>>> On 11.06.13 at 12:46, Roger Pau Monne <roger.pau@xxxxxxxxxx> 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






_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel