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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

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

Thanks,
Kevin

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