From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LOw4M-0006gK-Ah for qemu-devel@nongnu.org; Mon, 19 Jan 2009 10:29:42 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LOw4L-0006fe-MY for qemu-devel@nongnu.org; Mon, 19 Jan 2009 10:29:41 -0500 Received: from [199.232.76.173] (port=54921 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LOw4L-0006fS-Cl for qemu-devel@nongnu.org; Mon, 19 Jan 2009 10:29:41 -0500 Received: from mx2.redhat.com ([66.187.237.31]:53333) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LOw4K-0006UU-VM for qemu-devel@nongnu.org; Mon, 19 Jan 2009 10:29:41 -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 n0JFTepZ017638 for ; Mon, 19 Jan 2009 10:29:40 -0500 Message-ID: <49749C61.3080304@redhat.com> Date: Mon, 19 Jan 2009 17:29:37 +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> In-Reply-To: <49749AE1.8090400@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 Avi Kivity wrote: > Gerd Hoffmann wrote: >> Hmm, I'd like to see grant tables fit into this picture too. >> Using flags (instead of is_write) for map requests we can handle that >> too I think. We need a flag indicating we are passing a grant handle >> not a guest address, then we can stick the handle into addr (or make >> that a union). >> > > 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 - step 2: use cpu_physical_memory_{read,write,map}() to access the memory This makes grant tables transparent to the actual memory access API. -- error compiling committee.c: too many arguments to function