[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. David _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |