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: [Xen-ia64-devel] [RFC] grant table API clean up and performancetunin

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx>
Subject: Re: [Xen-ia64-devel] [RFC] grant table API clean up and performancetuning memo
From: Tristan Gingold <Tristan.Gingold@xxxxxxxx>
Date: Wed, 26 Apr 2006 13:44:26 +0200
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 26 Apr 2006 04:40:36 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <571ACEFD467F7749BC50E0A98C17CDD8094E7A05@pdsmsx403>
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>
References: <571ACEFD467F7749BC50E0A98C17CDD8094E7A05@pdsmsx403>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.5
Le Mardi 28 Mars 2006 15:04, Tian, Kevin a écrit :
> From: Isaku Yamahata [mailto:yamahata@xxxxxxxxxxxxx]
>
> >Sent: 2006年3月28日 20:27
> >
> >Without tracking a virtual address corresponding to a granted page,
> >xen/ia64 have to flush all tlb/vhpt.
> >I.e. xen/ia64 has to do something like
> >    vhpt_flush();
> >    flush_tlb_all();
> >Here vhpt_flush() flushes the whole of vhpt table.
> >
> >On the other hand, dom0 knows the virtual address so
> >dom0 may issues ptc.ga with page size (16KB by default).
> >It results in vcpu_ptc_ga() of xen/ia64.
> >It does
> >    vhpt_flush_address(vadr,addr_range);
> >    ia64_global_tlb_purge(vadr,vadr+addr_range,PAGE_SHIFT);
> >Here vhpt flush range is 16kb.
> >
> >If xen/ia64 tracks a virtual address somehow,
> >Xen/ia64 can flush vhpt with page size range so this become
> >meaningless.
>
> See your point now. :-) So how about pass the virtual address prepared
> for the granted page in host_addr at mapping time, though it's dom0 to
> setup mapping right after(or even before) the grant mapping call? By
> this way, though grant table doesn't setup the va mapping for guest, va is
> recorded and later you can take that info to do more accurate flush.
Two questions:
It seems your mechanism still need to trust the domains.  So we need to add 
checks for itc/ptc.

However, can a granted page be mapped several times ?
If so, tracking is necessary and has a cost.

From my point of view and my experience, flushing all the tlb/vhpt is really 
costly (and even more with SMP-g), but it is necessary.

Currently, we *don't* flush tlb/vhpt after unmapping granted page.  This 
really creates instability (at least of gcc segfaults).

I don't have yet a magic solution.  I think we need to fix gcc segfault bug 
first, and then we need to improve performance.

Tristan.



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