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] stale TLB contents?

To: George Dunlap <dunlapg@xxxxxxxxx>
Subject: Re: [Xen-devel] stale TLB contents?
From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Date: Mon, 24 Jan 2011 14:23:39 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 24 Jan 2011 05:24:23 -0800
Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=juergen.gross@xxxxxxxxxxxxxx; q=dns/txt; s=s1536b; t=1295875422; x=1327411422; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; z=Message-ID:=20<4D3D7D5B.4010204@xxxxxxxxxxxxxx>|Date:=20 Mon,=2024=20Jan=202011=2014:23:39=20+0100|From:=20Juergen =20Gross=20<juergen.gross@xxxxxxxxxxxxxx>|MIME-Version: =201.0|To:=20George=20Dunlap=20<dunlapg@xxxxxxxxx>|CC:=20 "xen-devel@xxxxxxxxxxxxxxxxxxx"=20<xen-devel@xxxxxxxxxxxx rce.com>|Subject:=20Re:=20[Xen-devel]=20stale=20TLB=20con tents?|References:=20<4D3D780A.4030001@xxxxxxxxxxxxxx>=20 <AANLkTimmgCkO4HASxdks=3DeAyy9QKyGZ+Gvt6UnavRG33@xxxxxxxx il.com>|In-Reply-To:=20<AANLkTimmgCkO4HASxdks=3DeAyy9QKyG Z+Gvt6UnavRG33@xxxxxxxxxxxxxx>|Content-Transfer-Encoding: =207bit; bh=X79tx5v1KfO8mS4ULMDLnG5hUvXZ4VJJIUoddHb3PIA=; b=P1pgT/uDl8QZIcDvY26IzKAgPBSQlwX/Kk4+HZGPC3r2sV3MWCCANnvT Y4W0bb3Y5v3jt8kpmysVNTgHIqNAsbiPGU+W2HmWM3L4p3Z++H6jd2uS7 11+85GKQmeLCcAn5zVFTHdei7kCTgW0naat5+tCjc6YYjA3IhHrH3asgg epyjABYTlptj1uNa0j3BR1LN4xPP8eVeDMADXdsrnbLoMfSHDIz9VXvoA JG1a5z/6xCsdzl/ocrXeHjaXTIgGv;
Domainkey-signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=G4SLaOYTEsxHeakxrevkTTpPBnPq7vYzxKn+VT5vDVV5/d/eSYpLe6Go vXe42IZkEiBqJrYBI8OIqGmF3lJDwND4aXbOsPPvNsT4azW331/Jat+uq op4o1Rr1hvvKdtolyMWGPsKy9u89oJ1y4Zm9+91aKQChZt+gLJxJIbB0W GMHHQPzg0oxdKd0oovLzTeArf4ekBOjuC7ZLYw5SrrXps6EdiVRng/dfH kDWvzym9ANHfTe8/B0FWQxBAhGV5l;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTimmgCkO4HASxdks=eAyy9QKyGZ+Gvt6UnavRG33@xxxxxxxxxxxxxx>
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>
Organization: Fujitsu Technology Solutions
References: <4D3D780A.4030001@xxxxxxxxxxxxxx> <AANLkTimmgCkO4HASxdks=eAyy9QKyGZ+Gvt6UnavRG33@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11
On 01/24/11 14:11, George Dunlap wrote:
If you're talking about just TLB  stuff (not changes to the EPT
tables), that should happen as a result of the context switch code
(nothing to do with EPT).  The code in question is here:

xen/arch/x86/domain.c:context_switch()
     if ( unlikely(!cpu_isset(cpu, dirty_mask)&&  !cpus_empty(dirty_mask)) )
     {
         /* Other cpus call __sync_local_execstate from flush ipi handler. */
         flush_tlb_mask(&dirty_mask);
     }

"Dirty  mask" means "where this vcpu has run"; since the vcpu in
question will have run on another pcpu, this should happen before the
vcpu is allowed to run on cpu 0 again.

Really?
I think you refer to this code in __context_switch():
    /*
     * Mark this CPU in next domain's dirty cpumasks before calling
     * ctxt_switch_to(). This avoids a race on things like EPT flushing,
     * which is synchronised on that function.
     */
    if ( p->domain != n->domain )
        cpu_set(cpu, n->domain->domain_dirty_cpumask);
    cpu_set(cpu, n->vcpu_dirty_cpumask);

This should set the dirty bit for the physical cpu on which the vcpu is just
about to be started.

But the dirty bit of the previous vcpu is cleared a little bit later:
    if ( p->domain != n->domain )
        cpu_clear(cpu, p->domain->domain_dirty_cpumask);
    cpu_clear(cpu, p->vcpu_dirty_cpumask);

Couldn't this leave the dirty mask to be empty again?


Juergen

--
Juergen Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@xxxxxxxxxxxxxx
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

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

<Prev in Thread] Current Thread [Next in Thread>