Re: [Xen-ia64-devel] PATCH: cleanup of tlbflush

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

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