From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LOwwN-0006Wc-S2 for qemu-devel@nongnu.org; Mon, 19 Jan 2009 11:25:31 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LOwwN-0006WP-EK for qemu-devel@nongnu.org; Mon, 19 Jan 2009 11:25:31 -0500 Received: from [199.232.76.173] (port=53460 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LOwwN-0006WK-99 for qemu-devel@nongnu.org; Mon, 19 Jan 2009 11:25:31 -0500 Received: from mx2.redhat.com ([66.187.237.31]:54212) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LOwwM-00043F-Qd for qemu-devel@nongnu.org; Mon, 19 Jan 2009 11:25:31 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n0JGPNQ5031576 for ; Mon, 19 Jan 2009 11:25:23 -0500 Message-ID: <4974A970.2090805@redhat.com> Date: Mon, 19 Jan 2009 18:25:20 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API References: <1232308399-21679-1-git-send-email-avi@redhat.com> <1232308399-21679-2-git-send-email-avi@redhat.com> <18804.34053.211615.181730@mariner.uk.xensource.com> <497496B2.8020107@redhat.com> <49749AE1.8090400@redhat.com> <49749C61.3080304@redhat.com> <4974A2DC.6020106@redhat.com> In-Reply-To: <4974A2DC.6020106@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Gerd Hoffmann wrote: > Avi Kivity wrote: > >>> Grant handles should be handled by a different API. >>> >> That was terse... here's how I think it should be done: >> >> - step 1: map the grant handle into guest physical memory >> > > Haha. > > Right :) > Guess I should explain a bit more what grant handles are ... > > A xen domain can give other domains permission to map specific pages. > This is called a grant. This is used by xen paravirtual drivers. The > domU frontend driver hands out grants to the backend driver (usually > dom0), so the backend driver can fill the guest buffers with the data. > > I want qemu be able to handle the backend side, so it must be able to > map and unmap grants. I think fitting this into the memory mapping API > can be useful, especially if the mapping API starts to get used by > generic code. Maybe the block layer some day accepts iovecs with guest > physical addresses and does map/unmap transparently? Then I'd like to > be able to pass in a iovec with grants instead. > Well, I still think it should be done by a separate API. Multiplexing target addresses and grant handles on the same API is messy. The block driver should keep its host virtual address interface; maybe we'll add a layer that accepts sglists on top of it; in that case we can add another API that accepts sglists that contain grant handles instead of addresses. -- error compiling committee.c: too many arguments to function