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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 12/06/13 08:41, Jan Beulich wrote:
>>>> On 11.06.13 at 20:09, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 11/06/13 18:02, Keir Fraser wrote:
>>> On 11/06/2013 17:41, "Roger Pau Monne" <roger.pau@xxxxxxxxxx> wrote:
>>>
>>>> Call update_domain_wallclock_time on hvm_latch_shinfo_size even if
>>>> the bitness of the guest has already been set, this fixes the problem
>>>> with the wallclock not being set for PVHVM guests on resume from
>>>> migration.
>>>>
>>>> Signed-off-by: Roger Pau Monnà <roger.pau@xxxxxxxxxx>
>>>> Cc: Jan Beulich <JBeulich@xxxxxxxx>
>>>> Cc: Keir Fraser <keir@xxxxxxx>
>>>> Cc: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
>>> May as well write directly into d->arch.has_32bit_shinfo and get rid of
>>> new_has_32bit. But apart from that:
>>>
>>> Acked-by: Keir Fraser <keir@xxxxxxx>
>> Yikes - we have had a patch in the XenServer patch queue for donkeys
>> years which implements the same fix as this.
>>
>> I had still not manage to decide whether it was a gross hack which we
>> needed to discard or whether it needed upstreaming.
>>
>> I guess this answers the question.
> Sounds like an ack/review then...
>
> Jan

Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

On closer inspection our patch is not actually so similar, but it still
is achieving the same effect using a rather more convoluted method.

I am rather embarrased to say that the patch in our queue completely
abuses HVM_PARAM_32BIT, value 8 (which is why that value is curiously
missing upstream, given HVM_PARAM_VIRIDIAN at 9)

~Andrew

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