[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.