From: Kouya Shimura <kouya@jp.fujitsu.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
xen-devel@lists.xen.org
Subject: Re: [PATCH 2/2] x86/hvm: fix corrupt ACPI PM-Timer during live migration
Date: Fri, 22 Mar 2013 10:12:35 +0900 [thread overview]
Message-ID: <514BB003.1070903@jp.fujitsu.com> (raw)
In-Reply-To: <514AE87902000078000C76E3@nat28.tlf.novell.com>
On 03/21/2013 07:01 PM, Jan Beulich wrote:
>>>> On 21.03.13 at 08:32, Kouya Shimura <kouya@jp.fujitsu.com> wrote:
>> @@ -244,19 +245,11 @@ static int handle_pmt_io(
>> static int pmtimer_save(struct domain *d, hvm_domain_context_t *h)
>> {
>> PMTState *s = &d->arch.hvm_domain.pl_time.vpmt;
>> - uint32_t x, msb = s->pm.tmr_val & TMR_VAL_MSB;
>> int rc;
>>
>> spin_lock(&s->lock);
>>
>> - /* Update the counter to the guest's current time. We always save
>> - * with the domain paused, so the saved time should be after the
>> - * last_gtime, but just in case, make sure we only go forwards */
>
> So on the previous patch version (which you said this one is
> identical to) I stated that you lose this property of guaranteeing
> no backward move. Am I right in assuming that patch 1 is now
> supposed to take care of this?
Yes. Patch 1 guarantees that the timer counter only goes forwards.
> In any case I'll have to defer to Keir or Tim for that first one.
>
>> - x = ((s->vcpu->arch.hvm_vcpu.guest_time - s->last_gtime) * s->scale) >> 32;
>> - if ( x < 1UL<<31 )
>> - s->pm.tmr_val += x;
>> - if ( (s->pm.tmr_val & TMR_VAL_MSB) != msb )
>> - s->pm.pm1a_sts |= TMR_STS;
>> + pmt_update_time(s, 0);
>
> Here I can only quote part of my previous reply, which I don't
> think you responded to:
>
> "Also, in delay_for_missed_ticks mode you now use a slightly
> different time for updating s->pm - did you double check that
> this is not going to be a problem? Or else, the flag above could
> similarly be used to circumvent this, or hvm_get_guest_time()
> could be made return the frozen time (I suppose, but didn't
> verify - as it appears to be an assumption already before your
> patch -, that pt_freeze_time() runs before pmtimer_save())."
>
> You said you'd think about it, but I don't recall seeing any other
> outcome from that than the two patches, and I can't relate the
> first patch to this aspect.
In patch 1, pmt_update_time() calls the new function hvm_get_base_time()
which returns the frozen time when the vcpu is de-scheduled.
And I confirmed pmtimer_save() is surely called after pt_freeze_time()
from my test and review.
So, if both patches are applied, there is no difference in
delay_for_missed_ticks mode.
Thanks,
Kouya
next prev parent reply other threads:[~2013-03-22 1:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-05 6:12 [PATCH] x86/hvm: fix corrupt ACPI PM-Timer during live migration Kouya Shimura
2013-02-12 12:26 ` Jan Beulich
2013-02-14 6:09 ` Kouya Shimura
2013-02-15 16:45 ` Jan Beulich
2013-02-20 7:42 ` Kouya Shimura
2013-03-07 15:58 ` Jan Beulich
2013-03-08 7:59 ` Kouya Shimura
2013-03-21 7:31 ` Kouya Shimura
2013-03-21 8:05 ` Jan Beulich
[not found] ` <514A9BC4.40508@jp.fujitsu.com>
2013-03-21 7:32 ` [PATCH 1/2] x86/hvm: prevent guest's timers from going backwards, when timer_mode=0 Kouya Shimura
2013-03-21 7:32 ` [PATCH 2/2] x86/hvm: fix corrupt ACPI PM-Timer during live migration Kouya Shimura
2013-03-21 10:01 ` Jan Beulich
2013-03-22 1:12 ` Kouya Shimura [this message]
2013-03-22 8:02 ` Jan Beulich
2013-05-15 14:23 ` Alex Bligh
2013-05-15 14:31 ` Jan Beulich
2013-05-15 14:49 ` Alex Bligh
2013-05-15 14:54 ` Jan Beulich
2013-05-16 5:29 ` Kouya Shimura
2013-05-16 10:38 ` Alex Bligh
2013-05-16 5:27 ` Kouya Shimura
2013-05-16 9:54 ` Tim Deegan
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=514BB003.1070903@jp.fujitsu.com \
--to=kouya@jp.fujitsu.com \
--cc=JBeulich@suse.com \
--cc=keir@xen.org \
--cc=tim@xen.org \
--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.