WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 0 of 5] PV on HVM Xen

On Tue, 16 Mar 2010, Jeremy Fitzhardinge wrote:
> On 03/16/2010 04:07 AM, Stefano Stabellini wrote:
> > OK, you are right: having an explicit "set/remove tsc offset" is
> > the best solution.
> >    
> 
> I wonder if we should include scale in that API, since I think future 
> CPUs will allow that to be set too.  (If its not supported, then the 
> call will fail if the scale is anything other than 1.)
> 

Actually I think Ian is right, we can do it without a new hypercall: if
we assume tsc_mode=2 then this simple patch makes the pv clocksource work
fine without any set_tsc_offset(v, 0) in xen:

---

diff -r 120b0e774c41 xen/arch/x86/time.c
--- a/xen/arch/x86/time.c       Mon Mar 15 15:05:15 2010 +0000
+++ b/xen/arch/x86/time.c       Tue Mar 16 17:26:08 2010 +0000
@@ -852,6 +852,10 @@
         _u.tsc_to_system_mul = t->tsc_scale.mul_frac;
         _u.tsc_shift         = (s8)t->tsc_scale.shift;
     }
+    if ( is_hvm_domain(d) )
+    {
+        _u.tsc_timestamp += v->arch.hvm_vcpu.cache_tsc_offset;
+    }
 
     /* Don't bother unless timestamp record has changed or we are forced. */
     _u.version = u->version; /* make versions match for memcmp test */

---

I tested this patch with my enhanced PV on HVM patch series.
If tsc_mode==1 everything gets more complicated, maybe Dan would know
what we need there to make it work.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel