From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH v6 6/8] xen/arm: introduce GNTTABOP_cache_flush Date: Thu, 16 Oct 2014 18:03:05 +0100 Message-ID: <543FFA49.60101@citrix.com> References: <1413470755-30991-6-git-send-email-stefano.stabellini@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1413470755-30991-6-git-send-email-stefano.stabellini@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini , xen-devel@lists.xensource.com Cc: julien.grall@citrix.com, Ian.Campbell@citrix.com List-Id: xen-devel@lists.xenproject.org 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