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: the P2M/VP patch merge plan (was Re: [Xen-ia64-devel] [PATCH][RFC][T

To: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Subject: Re: the P2M/VP patch merge plan (was Re: [Xen-ia64-devel] [PATCH][RFC][TAKE5] the P2M/VP patches)
From: Tristan Gingold <Tristan.Gingold@xxxxxxxx>
Date: Tue, 25 Apr 2006 17:27:22 +0200
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 25 Apr 2006 08:23:25 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060425012859.GC26453%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: <20060418141802.GG423%yamahata@xxxxxxxxxxxxx> <200604241621.27410.Tristan.Gingold@xxxxxxxx> <20060425012859.GC26453%yamahata@xxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.5
Le Mardi 25 Avril 2006 03:28, Isaku Yamahata a écrit :
> On Mon, Apr 24, 2006 at 04:21:27PM +0200, Tristan Gingold wrote:
> > just a question: is P2M/VP SMP-h/g safe ?
> > Please do the merge even if not yet SMP ready.  I will work to re-enable
> > SMP.
>
> Unfortunately no for both SMP-h/g.
> It doesn't boot without nosmp xen boot option because the P2M table
> is not protected at least.
> A lock sould be introduced to protect it.
> Please define a wrapper function, something like p2m_lock()/p2m_unlock().
> Prehaps read/write spin lock might be better for performance,
> but it can be tuned later. We should use simple spin lock as a first step.
After a quick look, I do not understand why we must protect writes to p2m.  I 
don't see possible incoherence.


BTW, the check_xen_dot_config_xen_ia64_dom0_virtual_physical in 
xen-mkbuildtree-pre seems broken.  The grep is wrong and is done too early.

Tristan.



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