[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.