[SPAM] Re: [Xen-devel] A patch to xen/arch/x86/hvm/pmtimer.c for both Xen 4.0.0 and Xen 4.0.1 to improve HVM scalability

[Song Xiang <classicxsong@xxxxxxxxx>]

We updated our patch as follows:

Index: arch/x86/hvm/pmtimer.c
===================================================================
--- arch/x86/hvm/pmtimer.c
+++ arch/x86/hvm/pmtimer.c
@@ -206,13 +206,23 @@

     if ( dir == IOREQ_READ )
     {
-        spin_lock(&s->lock);
-        pmt_update_time(s);
-        *val = s->pm.tmr_val;
-        spin_unlock(&s->lock);
+        uint32_t tmp;
+        /*
+         * if acquired the PMTState lock then update the time
+         * else other vcpu is updating it ,it should be up to date.
+         */
+        tmp = atomic_read(&s-> ownership);
+        if (spin_trylock(&s->lock)) {
+            pmt_update_time(s);
+            *val = s->pm.tmr_val;
+            spin_unlock(&s->lock);
+            atomic_inc(&s-> ownership);
+        }
+        else {
+            while (tmp == atomic_read(&s-> ownership));
+
+             *val = s->pm.tmr_val;
+        }
         return X86EMUL_OKAY;
     }

Index: include/asm-x86/hvm/vpt.h
===================================================================
--- include/asm-x86/hvm/vpt.h
+++ include/asm-x86/hvm/vpt.h
@@ -120,6 +120,7 @@
     uint64_t scale;             /* Multiplier to get from tsc to  
timer ticks */
     struct timer timer;         /* To make sure we send SCIs */
     spinlock_t lock;
+   atomic_t ownership;
 } PMTState;

 struct pl_time {    /* platform time */


The key idea is, to keep the returned time fresh, any VCPU that fails  
to acquire the PMTState lock will wait until the PMTState lock holder  
updates the global virtual time, and then returns the freshest time.
We add a field in PMTState, named ownership. The PMTState->ownership  
can only be updated by the PMTState lock holder.It is updated after  
the PMTState lock holder has updated the global virtual time and  
released the MTState lock.  Other VCPUs that fail to acquire the  
PMTState lock will check whether the MTState->ownership is updated in  
a while loop.  When the PMTState->ownership is changed, the global  
virtual time must be the freshest, and can be returned to the guest OS.
The time returned to the guest in this patch is fresher than the  
previous one we have proposed.

在 2010-11-15，上午8:28， Jan Beulich 写道：

> > > > On 13.11.10 at 11:56, Song Xiang <classicxsong@xxxxxxxxx> wrote:
> > --- arch/x86/hvm/pmtimer.c      (revision 4651)
> > +++ arch/x86/hvm/pmtimer.c      (working copy)
> > @@ -206,10 +206,17 @@
> >
> >      if ( dir == IOREQ_READ )
> >      {
> > -        spin_lock(&s->lock);
> > -        pmt_update_time(s);
> > -        *val = s->pm.tmr_val;
> > -        spin_unlock(&s->lock);
> > +        /*
> > +         * if acquired the PMTState lock then update the time
> > +         * else other vcpu is updating it ,it should be up to date.
> > +         */
> > +        if (spin_trylock(&s->lock)) {
> > +            pmt_update_time(s);
> > +            *val = s->pm.tmr_val;
> > +            spin_unlock(&s->lock);
> > +        }
> > +        else
> > +            *val = (s->pm.tmr_val & TMR_VAL_MASK);
> >          return X86EMUL_OKAY;
> >      }
> I don't think this is correct: While it seems reasonable to skip the
> global update, returning potentially stale time to the guest isn't.
> You'd need to mimic what pmt_update_time() does, just without
> updating global state. That, however, isn't going to be that
> trivial as you need to also read global state for doing the
> calculations.
>
> Jan

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