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/
Home Products Support Community News


Re: [Xen-ia64-devel] [RFC] SMP issues

To: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-ia64-devel] [RFC] SMP issues
From: Tristan Gingold <Tristan.Gingold@xxxxxxxx>
Date: Wed, 14 Jun 2006 10:30:11 +0200
Delivery-date: Wed, 14 Jun 2006 01:25:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060614055820.GE25157%yamahata@xxxxxxxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20060614055820.GE25157%yamahata@xxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.5
Le Mercredi 14 Juin 2006 07:58, Isaku Yamahata a écrit :
> Hello.
> - races between global tlb purge and tlb insert
>   This is a race between reading/writing vcpu->arch.{d, i}tlb or VHPT
> entry. When a vcpu is about to insert tlb, another vcpu may purge tlb
>   cache globally. Inserting tlb (vcpu_itc_no_srlz()) or global tlb purge
>   (domain_flush_vtlb_range() and domain_flush_vtlb_all()) can't update
>   cpu->arch.{d, i}tlb, VHPT and mTLB. So there is a race here.
>   Use sequence lock to avoid this race.
>   After inserting tlb entry, check the sequence lock and retry to insert.
>   This means that when global tlb purge and tlb insert are issued
>   simultaneously, always tlb insert happens after global tlb purge.
>   There was an attempt to resolve this race by checking only
>   vcpu->arch.{d, i}tlb.p bit. However it was incomplete because it doesn't
>   take care of VHPT.
I don't agree with the last paragraph.

During a flush, p bit was cleared first and then VHPT.
Races were avoided between Xen reads and Xen writes because the clear is 
There is no races between VHPT walker and Xen because either the walker reads 
before the VHPT clear (as if the reads occured before the ptc.ga) or fails 
(as if the access occured after the ptc.ga).


Xen-ia64-devel mailing list

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