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][TA

To: "Tristan Gingold" <Tristan.Gingold@xxxxxxxx>, "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: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Wed, 26 Apr 2006 10:47:54 +0800
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 25 Apr 2006 19:48:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZofDr9ALmxuPFAQimQUEEoEMv6FwAXtATQ
Thread-topic: the P2M/VP patch merge plan (was Re: [Xen-ia64-devel][PATCH][RFC][TAKE5] the P2M/VP patches)
>From: Tristan Gingold
>Sent: 2006年4月25日 23:27
>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.

It's unlikely to see two VCPUS requesting to modify same entry of 
p2m table at the same time, however it's likely that intermediate level 
like pmd doesn't exist for two simultaneously modification requests. 
At that time, two paths may both allocate a heap page and try to attach 
to p2m table. Some checks are definitely required here. Bit lock is 
always simplest thing to do and later you can do finer tuning like Isaku 
mentioned.

Thanks,
Kevin

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

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