From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48187) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDcFm-000364-J2 for qemu-devel@nongnu.org; Tue, 11 Oct 2011 09:20:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RDcFg-0005SW-Vh for qemu-devel@nongnu.org; Tue, 11 Oct 2011 09:20:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:7090) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDcFg-0005SG-Og for qemu-devel@nongnu.org; Tue, 11 Oct 2011 09:20:12 -0400 Message-ID: <4E944298.1010409@redhat.com> Date: Tue, 11 Oct 2011 15:20:24 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <20111002132436.GD11521@bow.tlv.redhat.com> <4E94284C.2000005@redhat.com> <20111011121529.GA1049@bow.tlv.redhat.com> In-Reply-To: <20111011121529.GA1049@bow.tlv.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Spice-devel] viewing continuous guest virtual memory as continuous in qemu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, spice-devel@freedesktop.org, Dave Airlie Hi, >> Another option we can think about is a 64bit PCI bar for the >> surfaces which can be moved out of the low 4G. > > I heard this suggested by Avi, so this would allow us to allocate a > large chunk without requiring any memory hole? You still need some address space for it, but as it isn't limited to 32bit addresses it can be mapped somewhere above 4G, i.e. we don't have to squeeze it into the 512MB pci hole at 0xe0000000. We can easily create a qxl gfx card with 1G of vram (aka surface) memory. Only question is how to handle that in a backward compatible way. We have regions 4+5 in pci config space still unused. 64bit bars need two entries, so adding a 64bit bar would use up both. The new 64bit vram bar would cover all vram memory. The old 32bit vram bar would be a window to the first 32 or 64 MB of vram memory. We could probably even create some register to make the 32bit bar window offset configurable, so you can access all vram memory using the 32bit bar, just not all at the same time. Not sure the latter is worth the effort with the world moving to 64bit. cheers, Gerd