Re: [Xen-devel] [PATCH 3/4] xen/arm: introduce XENMEM_cache_flush

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 02.10.14 at 13:57, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Thu, 2 Oct 2014, Jan Beulich wrote:
>> But again I don't see why Dom0 can't track state for the mappings
>> it establishes - after all, a grant-ref would be the most natural
>> thing to pass in here.
> 
> I agree it would be more natural to pass the grant-ref, but if Linux
> knew the grant-ref it wouldn't need the hypercall: it would also know
> the pfn and could just perform the flush on the pseudo-physical address.
> 
> See drivers/xen/swiotlb-xen.c: the dma_map_ops api only gives us an mfn
> at unmap time. Maintaining an mfn_to_pfn (or to grant_ref) tree with
> multiple entries per mfn is expensive. The tree would need to be global:
> maintained for every grant map/unmap operation, that nowadays happen
> extremely often with netfront/netback. In addition the lookup is not
> very fast either. We would also need to take a lock to be able to handle
> the multiple grants for the same page scenario.

I don't follow: The first thing xen_unmap_single() does is get
the physical address for the passed in DMA one. Furthermore,
if only SWIOTLB code is of concern, then this is limited size,
and hence you could have a xen_io_tlb_nslabs-element array
tracking whatever additional information you may need for
each of the slabs.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel