xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Sheng Yang <sheng@linux.intel.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	Ian Pratt <Ian.Pratt@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Tim Deegan <Tim.Deegan@citrix.com>,
	Keir Fraser <Keir.Fraser@eu.citrix.com>
Subject: Re: Re: [PATCH][v4] PV extension of HVM(hybrid) support in	Xen
Date: Tue, 2 Mar 2010 11:36:02 +0800	[thread overview]
Message-ID: <201003021136.02590.sheng@linux.intel.com> (raw)
In-Reply-To: <4B8C6EC3.2020307@goop.org>

On Tuesday 02 March 2010 09:49:55 Jeremy Fitzhardinge wrote:
> On 03/01/2010 03:40 AM, Sheng Yang wrote:
> > The issue is pv timer. It assumed the tsc start from 0, which is
> > different from HVM. So I'd like to give it a explicit call here.
> > Otherwise it can be hooked in evtchn binding, but I don't think that's
> > clear...
> 
> [...]
> 
> >> Only vcpu 0?  Doesn't this do horrible things to timekeeping in the
> >> guest?
> >
> > The other vcpus are initialized when it is brought up. TSC started from 0
> > is a fundamental assumption for pv clock in Linux...
> 
> Could you expand on this?  Do you mean in the pvops Xen time code?  What
> do you mean?
> 

The function pvclock_get_nsec_offset() in Linux kernel have this:

>static u64 pvclock_get_nsec_offset(struct pvclock_shadow_time *shadow)
>{
>        u64 delta = native_read_tsc() - shadow->tsc_timestamp;
>        return scale_delta(delta, shadow->tsc_to_nsec_mul, shadow-
>tsc_shift);
>}

tsc_timestamp take the vcpu beginning at 0, so that's the assumption. So I 
adjusted guest TSC(the return value of native_read_tsc()) to satisfy this 
assumption. 

-- 
regards
Yang, Sheng

  reply	other threads:[~2010-03-02  3:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-01  9:43 [PATCH][v4] PV extension of HVM(hybrid) support in Xen Sheng Yang
2010-03-01 10:00 ` Keir Fraser
2010-03-01 10:52   ` Stefano Stabellini
2010-03-01 10:21 ` Tim Deegan
2010-03-01 11:40   ` Sheng Yang
2010-03-02  1:49     ` Jeremy Fitzhardinge
2010-03-02  3:36       ` Sheng Yang [this message]
2010-03-02  4:39         ` Jeremy Fitzhardinge
2010-03-02  5:04           ` Sheng Yang
2010-03-02  5:21             ` Jeremy Fitzhardinge

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=201003021136.02590.sheng@linux.intel.com \
    --to=sheng@linux.intel.com \
    --cc=Ian.Campbell@eu.citrix.com \
    --cc=Ian.Pratt@eu.citrix.com \
    --cc=Keir.Fraser@eu.citrix.com \
    --cc=Tim.Deegan@citrix.com \
    --cc=jeremy@goop.org \
    --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).