xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
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

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