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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 2 Oct 2014, Jan Beulich wrote:
> >>> On 02.10.14 at 13:41, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> > On Thu, 2 Oct 2014, Jan Beulich wrote:
> >> With that, wouldn't the whole operation be a better fit with
> >> the other MMUEXT_* ones instead of being XENMEM_*?
> > 
> > Or maybe a GNTTABOP_?
> > After all we are only interested in flushing foreign pages with the
> > hypercall. It would still need to take an mfn (or better a dev_bus_addr)
> > because dom0 doesn't know the grant_ref either.
> 
> If the op is really meant to only be used on grants, then yes,
> XENMEM_ as well as MMUEXT_ would seem the wrong ones (but
> then you also incorrectly implemented it, as right now it permits
> flushes on non-foreign pages).
> 
> 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.

On the other hand we need to call the hypercall only at the end of dma
operations performed on foreign grants with non-coherent devices.
On a well designed board, having SMMUs and/or coherent devices
everywhere, the hypercall would never need to be called.

In the SoCs we have today network cards tend to be coherent and SATA
controllers not to be: I wouldn't want to penalize the network
performance.

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