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] A patch to xen/arch/x86/hvm/pmtimer.c for both Xen 4.0.0

To: "Song Xiang" <classicxsong@xxxxxxxxx>
Subject: 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
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Mon, 15 Nov 2010 08:28:49 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Haibo Chen <oldseawave@xxxxxxxxx>
Delivery-date: Mon, 15 Nov 2010 00:29:46 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1208B612-80C6-4009-ACEB-1D4E99D0FA7E@xxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1208B612-80C6-4009-ACEB-1D4E99D0FA7E@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> 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