From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LOxjd-0000MN-Qm for qemu-devel@nongnu.org; Mon, 19 Jan 2009 12:16:25 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LOxjZ-0000Lp-2J for qemu-devel@nongnu.org; Mon, 19 Jan 2009 12:16:25 -0500 Received: from [199.232.76.173] (port=35638 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LOxjY-0000Lk-TI for qemu-devel@nongnu.org; Mon, 19 Jan 2009 12:16:20 -0500 Received: from mx2.redhat.com ([66.187.237.31]:56290) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LOxjY-0000Z5-8O for qemu-devel@nongnu.org; Mon, 19 Jan 2009 12:16:20 -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 n0JHGJcr009207 for ; Mon, 19 Jan 2009 12:16:19 -0500 Message-ID: <4974B560.4090804@redhat.com> Date: Mon, 19 Jan 2009 19:16:16 +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> <18804.45977.473458.280620@mariner.uk.xensource.com> In-Reply-To: <18804.45977.473458.280620@mariner.uk.xensource.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 Ian Jackson wrote: > Gerd Hoffmann writes ("Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API"): > >> Avi Kivity wrote: >> [Avi:] >> >>>> 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 >>> > > I agree that grant handles should be handled by a different API. But > I don't see why they need to be mapped into guest physical memory, or > referred to via a target_phys_addr_t at all. > > The only consumers of grant references in qemu are Xen-specific > backend drivers, and they can call the Xen-specific grant reference > APIs directly. There is no need for anyone but those backend drivers > to access those pages of guest memory. > > So I don't see why grant references are relevant to the > cpu_physical_memory_map API at all. > Thinko on my part. Wasn't a good suggestion. Side-by-side APIs seem best. -- error compiling committee.c: too many arguments to function