[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Thu, 2 Oct 2014, Jan Beulich wrote:
> >>> On 02.10.14 at 12:02, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> > --- a/xen/arch/arm/mm.c
> > +++ b/xen/arch/arm/mm.c
> > @@ -1134,6 +1134,98 @@ long arch_memory_op(int op, 
> >      case XENMEM_get_sharing_shared_pages:
> >      case XENMEM_get_sharing_freed_pages:
> >          return 0;
> > +    case XENMEM_cache_flush:
> Two further notes/questions:
> Shouldn't this rather be an arch-independent op right away?

May be a good idea

> I suppose x86 will need this the moment it gains 32-bit PVH Dom0
> support (which will then include non-PAE).

Only if non-coherent devices start appearing on x86 too: coherent
devices don't need cache flush operations. So in theory it could be
useful on x86 but in practice I don't think it would be used, at least

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

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.