From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel De Graaf Subject: Re: [PATCH 1/6] xenbus: Support HVM backends Date: Thu, 15 Dec 2011 09:38:47 -0500 Message-ID: <4EEA0677.5060100@tycho.nsa.gov> References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov> <1323893534-436-2-git-send-email-dgdegra@tycho.nsa.gov> <4EEA008E.5050002@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4EEA008E.5050002@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: David Vrabel Cc: Xen-devel@lists.xensource.com, konrad.wilk@oracle.com List-Id: xen-devel@lists.xenproject.org On 12/15/2011 09:13 AM, David Vrabel wrote: > On 14/12/11 20:12, Daniel De Graaf wrote: >> Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so >> that ring mappings can be done without using GNTMAP_contains_pte which >> is not supported on HVM. > > Perhaps rename the functions to xenbus_map_ring() and > xenbus_unmap_ring()? I wouldn't respin the series just for this though. > > Is there merit in having the pv and hvm variants, instead of just the > hvm variant? > > David > There are already functions called xenbus_{map,unmap}_ring - they do the actual mapping in the HVM case, with the _valloc versions just adding in memory alloc/free. The PV versions are slightly faster because they won't require additional page table updates. Otherwise, I believe that the HVM variant should work on both PV&HVM. -- Daniel De Graaf National Security Agency