WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

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

To: "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx>, "Tristan Gingold" <Tristan.Gingold@xxxxxxxx>
Subject: RE: the P2M/VP patch merge plan (was Re: [Xen-ia64-devel][PATCH][RFC][TAKE5] the P2M/VP patches)
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Wed, 26 Apr 2006 11:21:33 +0800
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 25 Apr 2006 20:21:48 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZo31NGXYnCnqUtSteLJy/iSpyX8wAADdRw
Thread-topic: 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

<Prev in Thread] Current Thread [Next in Thread>