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: Wed, 26 Apr 2006 09:49:24 +0200
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 26 Apr 2006 00:45:29 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060426031242.GC30680%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> <200604251727.22976.Tristan.Gingold@xxxxxxxx> <20060426031242.GC30680%yamahata@xxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.5
Le Mercredi 26 Avril 2006 05:12, Isaku Yamahata a écrit :
> On Tue, Apr 25, 2006 at 05:27:22PM +0200, Tristan Gingold wrote:
> > 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.
>
> The following is what I notice now.
>
> - pgd_populate(), pud_populate(), pmd_populate()
>   What if two cpu try to populate same virtual address?
>   Given that page allocation on demand is now removed, it might be possible
>   to all necessary pgd/pud/pmd/pte page is allocate at domain creation.
>
> - guest_physmap_add_page()
>     assign_domain_page_replace()
>       ptep_get_and_clear()
>                       <<<<<<<<<<<< what if another cpu does set_pte() here?
>       set_pte()
>     set_gpfn_from_mfn()
>
> - memory ordering
>   set_pte() doesn't have any memory relase semantics.
>   And readers (i.e. *(pte)) doesn't have acquire semantics.
>   I guess some memory barrier is required.
>   (spin lock means memory barrier)
Ok, this is mostly SMP-g issues not SMP-h, isn't it ?

> > 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.
>
> I'm not satisfied with that.
> However I don't have any better idea. Do you have better idea?
The usual trick: copy both versions using a different name, the original file 
include the correct version according to CONFIG_ macro.

Tristan.



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