From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH RFC] xen/grant_table: deprecate GNTTABOP_unmap_and_replace Date: Mon, 22 Jul 2013 12:40:50 +0100 Message-ID: <51ED1A42.6050107@citrix.com> References: <1374428099-24328-1-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: <1374428099-24328-1-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 Cc: xen-devel@lists.xensource.com, keir@xen.org, Ian.Campbell@citrix.com, JBeulich@suse.com List-Id: xen-devel@lists.xenproject.org On 21/07/13 18:34, Stefano Stabellini wrote: > GNTTABOP_unmap_and_replace has two issues: > - it unconditionally replaces the mapping passed in new_addr with 0; > - it doesn't support GNTMAP_contains_pte mappings on x86, returning a > general error instead of some forms of ENOSYS. I don't think you can change the behavior of the existing sub-op in this way. XenServer's current netback driver relies on the current behaviour, for example. I think this will also mess up the ref counting on the frame that is at the new_addr virtual address. It will be mapped twice but with no additional ref count. I think the you can fix the problem in Linux without any hypervisor side changes, but adding a new sub-op for GNTTABOP_unmap_and_duplicate (unmap and replace with mapping with a duplicate of an existing mapping) will allow for batching. David