From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Ofsthun Subject: Re: [rfc] [patch] more 'long' in the hypervisor interface Date: Thu, 29 Jun 2006 13:55:51 -0400 Message-ID: <44A41427.2020904@virtualiron.com> References: <1151528600.11374.75.camel@basalt.austin.ibm.com> <20060628210948.GA11951@sequoia.sous-sol.org> <1151529702.11374.88.camel@basalt.austin.ibm.com> <20060628213623.GO11588@sequoia.sous-sol.org> <1151531916.11374.98.camel@basalt.austin.ibm.com> <20060628230500.GP11588@sequoia.sous-sol.org> <44A3E5C3.30305@virtualiron.com> <20060629170203.GU11588@sequoia.sous-sol.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20060629170203.GU11588@sequoia.sous-sol.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Chris Wright Cc: xen-devel , Hollis Blanchard , xen-ppc-devel List-Id: xen-devel@lists.xenproject.org Chris Wright wrote: > * Steve Ofsthun (sofsthun@virtualiron.com) wrote: > >>For HVM guests, the ABI is less established. I'm not sure anyone but us >>(Virtual Iron), is doing much with hypercalls from HVM guests. We are >>currently running paravirtualized drivers in HVM guests. As the code >>matures, we will be posting these patches. > > > Look forward to seeing that. So am I! ;) >>We have had to deal with issues separate from the mechanical ABI issues. >>For example, grant table transfers (used by the standard netfront/netback) >>don't play well with QEMU's one time direct map of the entire HVM guest >>address space. > > > What did you do here? Specifically, how much does the PV driver in HVM > guest diverge from normal PV guest? This will effect merging this code > into Linux which is why I care. We changed the netfront/netback to stop using grant table transfers. As an alternative, we preallocate receive buffers in netfront and pass them as grant references to netback. As netback receives new packets, the preallocated pool of buffers are dynamically mapped and data is copied in. This additional data copy is probably unacceptable for PV guests. We are just starting to analyze the performance impact. Two alternatives to this approach are available in the longer term. One is to create a new high performance device model in QEMU that reduces the per packet cost of the emulated NIC. There has been discussion about this, but I am not aware of any actual work in progress. Another approach is to retain the existing PV network driver and fix the inconsistencies between QEMU guest mappings and grant table transfer operations. Steve -- Steve Ofsthun - Virtual Iron Software, Inc.