From: Marek Marczykowski <marmarek@mimuw.edu.pl>
To: Keir Fraser <keir.xen@gmail.com>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
xen-devel@lists.xensource.com,
Joanna Rutkowska <joanna@invisiblethingslab.com>,
Rafal Wojtczuk <rafal@invisiblethingslab.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: xen-4.1: PV domain hanging at startup, jiffies stopped
Date: Wed, 31 Aug 2011 23:13:22 +0200 [thread overview]
Message-ID: <4E5EA3F2.10702@mimuw.edu.pl> (raw)
In-Reply-To: <CA845FD0.2013E%keir.xen@gmail.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 1950 bytes --]
On 31.08.2011 23:01, Keir Fraser wrote:
> On 31/08/2011 21:49, "Marek Marczykowski" <marmarek@mimuw.edu.pl> wrote:
>
>> xen_vcpuop_set_next_event schedules event by getting current time
>> (xen_clocksource_read()) (*1) adding delta (expires-now) and programming
>> event with VCPUOP_set_singleshot_timer hypercall. Then xen gets current
>> time (*2) and in some rare cases this time is after expected timer
>> expiration... Even after VCPUOP_set_singleshot_timer hypercal,
>> xen_clocksource_read() reports time slightly in the past comparing to
>> xen time (reported by NOW() macro).
>>
>> I think this is because "current" time is calculated different way in *1
>> and *2. The *1 way is controlled by tsc_mode, which is described here:
>> http://lxr.xensource.com/lxr/source/docs/misc/tscmode.txt. Default
>> tsc_mode=0 is "smart" and I think because of that can be slightly before
>> NOW() time. tsc_mode=2 looks almost the same as NOW() macro works.
>>
>> Is this reasoning correct?
>
> They really ought to work out to the same thing. This will trivially be the
> case with tsc_mode=2 because both guest and hypervisor will see the same
> (real) values from RDTSC, and use the same offsets and sacle factors to turn
> that into a current system time. When using emulated TSC in the guest
> (tsc_mode=0,1) then the TSC values it sees, and the offsets and scale
> factors it applies, are different. It is intended that it should result in
> the same values being computed for NOW(), but I suppose something could be
> going wrong there.
NOW() calls get_s_time() which doesn't look to be depended on tsc_mode
setting. Have I missed something?
> By how much have you seen guest and hypervisor disagree?
Adding printks in domU and hypervisor side using attached patches.
--
Pozdrawiam / Best Regards,
Marek Marczykowski | RLU #390519
marmarek at mimuw edu pl | xmpp:marmarek at staszic waw pl
[-- Attachment #1.1.2: debug-kernel-domU.diff --]
[-- Type: text/plain, Size: 967 bytes --]
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 5158c50..0976e44 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -332,16 +332,22 @@ static int xen_vcpuop_set_next_event(unsigned long delta,
int cpu = smp_processor_id();
struct vcpu_set_singleshot_timer single;
int ret;
+ s64 base;
WARN_ON(evt->mode != CLOCK_EVT_MODE_ONESHOT);
- single.timeout_abs_ns = get_abs_timeout(delta);
- single.flags = VCPU_SSHOTTMR_future;
+ base = xen_clocksource_read();
+ single.timeout_abs_ns = base + delta;
+ single.flags = VCPU_SSHOTTMR_future & 0;
ret = HYPERVISOR_vcpu_op(VCPUOP_set_singleshot_timer, cpu, &single);
BUG_ON(ret != 0 && ret != -ETIME);
+ if (ret == -ETIME) {
+ printk(KERN_WARNING "hypercall VCPUOP_set_singleshot_timer failed with -ETIME on %d CPU with params: timeout=%lld, flags=%d, base-pre: %lld, base-post: %lld\n", cpu, single.timeout_abs_ns, single.flags, base, get_abs_timeout(0));
+ }
+
return ret;
}
[-- Attachment #1.1.3: debug-xen.diff --]
[-- Type: text/plain, Size: 956 bytes --]
diff -r 227130622561 xen/common/domain.c
--- a/xen/common/domain.c Thu Aug 25 12:03:14 2011 +0100
+++ b/xen/common/domain.c Wed Aug 31 23:05:31 2011 +0200
@@ -896,6 +896,7 @@ long do_vcpu_op(int cmd, int vcpuid, XEN
case VCPUOP_set_singleshot_timer:
{
struct vcpu_set_singleshot_timer set;
+ s_time_t now;
if ( v != current )
return -EINVAL;
@@ -903,9 +904,12 @@ long do_vcpu_op(int cmd, int vcpuid, XEN
if ( copy_from_guest(&set, arg, 1) )
return -EFAULT;
+ now = NOW();
if ( (set.flags & VCPU_SSHOTTMR_future) &&
- (set.timeout_abs_ns < NOW()) )
+ (set.timeout_abs_ns < now) ) {
+ gdprintk(XENLOG_INFO, "VCPUOP_set_singleshot_timer: time in past: %lu < %ld\n", set.timeout_abs_ns, now);
return -ETIME;
+ }
migrate_timer(&v->singleshot_timer, smp_processor_id());
set_timer(&v->singleshot_timer, set.timeout_abs_ns);
[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5842 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2011-08-31 21:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-28 13:13 xen-4.1: PV domain hanging at startup, jiffies stopped Marek Marczykowski
2011-08-29 20:07 ` Konrad Rzeszutek Wilk
2011-08-29 20:21 ` Marek Marczykowski
2011-08-29 20:59 ` Konrad Rzeszutek Wilk
2011-08-29 21:28 ` Pasi Kärkkäinen
2011-08-30 17:18 ` Marek Marczykowski
2011-08-31 16:27 ` Marek Marczykowski
2011-08-31 20:00 ` Dan Magenheimer
2011-08-31 20:49 ` Marek Marczykowski
2011-08-31 21:01 ` Keir Fraser
2011-08-31 21:13 ` Marek Marczykowski [this message]
2011-08-31 22:07 ` Keir Fraser
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=4E5EA3F2.10702@mimuw.edu.pl \
--to=marmarek@mimuw.edu.pl \
--cc=dan.magenheimer@oracle.com \
--cc=joanna@invisiblethingslab.com \
--cc=keir.xen@gmail.com \
--cc=konrad.wilk@oracle.com \
--cc=rafal@invisiblethingslab.com \
--cc=xen-devel@lists.xensource.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).