All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH v2] xen: fix initialization of wallclock time for PVHVM on migration
Date: Wed, 12 Jun 2013 12:25:24 +0100	[thread overview]
Message-ID: <51B85AA4.3080705@citrix.com> (raw)
In-Reply-To: <51B8423802000078000DD704@nat28.tlf.novell.com>

On 12/06/13 08:41, Jan Beulich wrote:
>>>> On 11.06.13 at 20:09, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 11/06/13 18:02, Keir Fraser wrote:
>>> On 11/06/2013 17:41, "Roger Pau Monne" <roger.pau@citrix.com> 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@citrix.com>
>>>> Cc: Jan Beulich <JBeulich@suse.com>
>>>> Cc: Keir Fraser <keir@xen.org>
>>>> Cc: George Dunlap <George.Dunlap@eu.citrix.com>
>>> 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@xen.org>
>> 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@citrix.com>

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@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2013-06-12 11:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-11 16:41 [PATCH v2] xen: fix initialization of wallclock time for PVHVM on migration Roger Pau Monne
2013-06-11 17:02 ` Keir Fraser
2013-06-11 18:09   ` Andrew Cooper
2013-06-12  7:41     ` Jan Beulich
2013-06-12 11:25       ` Andrew Cooper [this message]
2013-06-12  9:36     ` Keir Fraser
2013-06-12 11:29       ` Andrew Cooper
2013-06-12  7:42   ` Jan Beulich
2013-06-12 10:06 ` George Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51B85AA4.3080705@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=keir.xen@gmail.com \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.