[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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)


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.