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

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

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)


> 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?

-- 
yamahata

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