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

Re: [Xen-ia64-devel] [PATCH][GFW][RFC] fix EFI_SAL_SET_VECTORS

To: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Subject: Re: [Xen-ia64-devel] [PATCH][GFW][RFC] fix EFI_SAL_SET_VECTORS
From: tgingold@xxxxxxx
Date: Wed, 14 May 2008 10:43:24 +0200
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 14 May 2008 01:47:01 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080514024000.GD17693%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: <20080513081113.GB12283%yamahata@xxxxxxxxxxxxx> <1210674256.48296c50ab2e8@xxxxxxxxxxx> <20080514024000.GD17693%yamahata@xxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Internet Messaging Program (IMP) 3.2.8
Quoting Isaku Yamahata <yamahata@xxxxxxxxxxxxx>:

> On Tue, May 13, 2008 at 12:24:16PM +0200, tgingold@xxxxxxx wrote:
> > > The uncached physical addresses are hard coded, but they aren't
> > > relocated when switching to virtual address mode.
> >
> > I am not sure ConvertPointer is able to deal with uncached addresses.
> Anyway,
> > using normal addresses should be harmless.
>
> I guess that the original auther concerned about a race so that
> he used uncached addresses.

I don't catch your point.  Uncached addresses won't prevent races.

> Anyway the variable size is 16 bytes and are written/read twice
> so that the access isn't smp safe.
> Possible choice would be
> a. don't care
>    assume that such a race won't happen and pray.
> b. use explicit lock
> c. use atomic access(cmp8xchg16)
> d. explicit synchronization betweeen cpus.
>    Probably this would be difficult in gfw.
>
> My bet is a.

I don't think that SAL has to protect against concurrency.  I can't
remember if the vector must be set for every processor.  I will look.

Tristan.

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