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