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

Re: [Xen-devel] [PATCH v6 6/8] xen/arm: introduce GNTTABOP_cache_flush

On 16/10/14 15:45, Stefano Stabellini wrote:
> Introduce a new hypercall to perform cache maintenance operation on
> behalf of the guest. The argument is a machine address and a size. The
> implementation checks that the memory range is owned by the guest or the
> guest has been granted access to it by another domain.
> Introduce grant_map_exists: an internal grant table function to check
> whether an mfn has been granted to a given domain on a target grant
> table.
> As grant_map_exists loops over all the guest grant table entries, limit
> DEFAULT_MAX_NR_GRANT_FRAMES to 10 to cap the loop to 5000 iterations
> max. Warn if the user sets max_grant_frames higher than 10.

No.  This is much too low.

A netfront with 4 queues wants 4 * 2 * 256 = 2048 grant references. So
this limit would only allow for two VIFs which is completely unacceptable.

blkfront would be similarly constrained.

I think you're going to have to add continuations somehow or you are
going to have abandon this approach and use the SWIOTLB in the guest.


Xen-devel mailing list



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