Re: the P2M/VP patch merge plan (was Re: [Xen-ia64-devel] [PATCH][RFC][TAKE5] the P2M/VP patches)

[Tristan Gingold <Tristan.Gingold@xxxxxxxx>]

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