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