From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JbJ3z-00064p-8n for qemu-devel@nongnu.org; Mon, 17 Mar 2008 13:23:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JbJ3y-00064H-IQ for qemu-devel@nongnu.org; Mon, 17 Mar 2008 13:23:54 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JbJ3y-000645-BL for qemu-devel@nongnu.org; Mon, 17 Mar 2008 13:23:54 -0400 Received: from bzq-179-150-194.static.bezeqint.net ([212.179.150.194] helo=il.qumranet.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JbJ3x-0003xE-RD for qemu-devel@nongnu.org; Mon, 17 Mar 2008 13:23:54 -0400 Message-ID: <47DEA908.4040907@qumranet.com> Date: Mon, 17 Mar 2008 19:23:20 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] phys_ram_base, direct access to guest memory References: <18398.33922.132796.510683@mariner.uk.xensource.com> In-Reply-To: <18398.33922.132796.510683@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: > As I think has been mentioned here a few times before, Xen is able to > support guests with more RAM than the host's (strictly, dom0's) > address space. For example, 64-bit guests with >4G RAM on 32-bit > hosts. For this and for other reasons, guest physical RAM is not > mapped into any host process. > > I don't expect qemu to take the Xen mapcache, which has been > extensively discussed and is apparently not well-regarded here. > > However, it would be very helpful if where reasonable parts of qemu > would avoid assuming that they can get at guest physical memory by use > of phys_ram_base. > > For example, in the loader in pc.c, simply adding phys_ram_base does > not work and we have to have a rather large patch to convert things to > use cpu_physical_memory_rw. The result is no more cumbersome - > indeed, it's slightly tidier in a few ways because there's less need > to constantly add and subtract phys_ram_base; the code can just deal > with guest physical addresses directly, as numbers, and leave the > actual memory access to the existing physical memory abstraction. > > So I think it would be nice to have that change in qemu upstream. > While it doesn't directly enable anything useful right away, the > result is slightly cleaner. I'll submit a proper patch shortly. > Actually it is quite useful, with the 4GB+ support qemu memory is not linear since the pci hole is skipped in phys_ram_base. -- error compiling committee.c: too many arguments to function