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 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.