[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>From: Isaku Yamahata
>Sent: 2006年4月26日 11:13
>> 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?

Why does 'virtual address' matter here? :-)

>
>- 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()

For single pte entry, I think it should be safe because it's always 
the owner of that gpfn will try to modify related p2m relationship. 
The virtual driver code in guest should ensure that or else 
set_phys_to_machine used by xen/x86 will see same trouble.

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

That's the one.

Thanks,
Kevin

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.