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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 11.06.13 at 15: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.

And it really isn't meant to deal with resume anyway. I simply based
my original response on your description of the change, which now
it looks like was misleading.

> Would it be OK to call
> update_domain_wallclock_time unconditionally on
> hvm_hypercall_page_initialise?

The primary question is - why is what we have not enough for you?
In particular I would expect that the call from arch_set_info_guest()
(for vCPU 0) should do what you want. Or wait, this is covering PV
only. So yes, with the description change I would then withdraw my
NACK - apparently no-one really used the shared info wall clock
time in a HVM guest so far (or it going wrong post-resume wasn't
noticed).

I would, however, prefer the if() immediately preceding the patch
context to be pulled out past the domain_lock()ed region, convert it
to switch(), and add your code. That was, eventual other post-
processing for the various map spaces has a consistent, easily
extensible home.

Jan

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