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] PATCH: cleanup of tlbflush

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Subject: Re: [Xen-ia64-devel] PATCH: cleanup of tlbflush
From: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Thu, 11 May 2006 11:03:42 +0900
Cc: Tristan Gingold <Tristan.Gingold@xxxxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 10 May 2006 19:03:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <571ACEFD467F7749BC50E0A98C17CDD8094E7BFC@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: <571ACEFD467F7749BC50E0A98C17CDD8094E7BFC@pdsmsx403>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
On Thu, May 11, 2006 at 09:26:28AM +0800, Tian, Kevin wrote:
> >From: Isaku Yamahata [mailto:yamahata@xxxxxxxxxxxxx]
> >Sent: 2006年5月11日 0:01
> >>
> >> The key point is to pass in the gva address (host_addr) which is
> >> previously mapped to granted frame. It's guest's responsibility to
> >record
> >> those mapped address and then passed in at unmap request. For
> >> example, xen/x86 use pre-allocated virtual address range while
> >xen/ia64
> >> uses identity-mapped one. It's current para-driver style and we can
> >> trust domain since guest needs to be cooperative or else domain itself
> >> is messed instead of xen.
> >>
> >> Isaku, how about your thought on it?
> >
> >I don't think that tracking virtual address cause much performance loss.
> >At least for vbd.
> 
> My point is, current para-driver already tracks virtual address in domain, 
> and we can do quick efficient support by simply implementing 
> destroy_grant_host_mapping to purge vhpt entry based on passed gva 
> upon receiving unmap request. If you suggestion about track in xen really 
> helps, that's a common enhancement which should be added for all but 
> can be done later.
> 
> I think the logic here is simple: domain assigns a virtual address to map 
> granted frame, and then later domain itself passes in same virtual address 
> to unmap granted frame. Xen simply helps domain upon its request.
> 
> >The reason is that a underlying block device doesn't need to
> >read its data. Then unmapping such a granted page doesn't require
> >any flush. (I'm just guessing. The md driver or lvm may read its
> >contents to calculate checksum though.)
> >We can enhance grant table to allow no-read/no-write(dma-only)
> >mapping.
> 
> That's OK to add to common code, if necessarily helps. But anyway, 
> there's no reason for flush_tlb_mask to purge whole VHPT tables, which 
> is overkill. First step I think is to follow syntax of unmap ops structure 
> which already ensures more efficiency than current flush all style and 
> it's easy.

I agree with you that a simple and certain way should be adopted
as a first step and that complex and uncertain thing should be
examined later.
In this case it is that xen should be given virtual addresses to
flush trusting dom0.

I have to admit that tracking virtual addresses would require
complex coding. I'm not sure its gain neigher.
-- 
yamahata

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