From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34150) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDbNC-000813-1W for qemu-devel@nongnu.org; Tue, 11 Oct 2011 08:23:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RDbNA-0000R8-56 for qemu-devel@nongnu.org; Tue, 11 Oct 2011 08:23:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27394) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDbN9-0000R3-Qr for qemu-devel@nongnu.org; Tue, 11 Oct 2011 08:23:52 -0400 Date: Tue, 11 Oct 2011 14:21:17 +0200 From: Alon Levy Message-ID: <20111011121529.GA1049@bow.tlv.redhat.com> References: <20111002132436.GD11521@bow.tlv.redhat.com> <4E94284C.2000005@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E94284C.2000005@redhat.com> 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: Gerd Hoffmann Cc: Dave Airlie , qemu-devel@nongnu.org, spice-devel@freedesktop.org On Tue, Oct 11, 2011 at 01:28:12PM +0200, Gerd Hoffmann wrote: > Hi, > > >AFAIU this works only when the guest allocates a continuous range of > >physical pages. This is a large requirement from the guest, which I'd > >like to drop. > > Is it? The world is moving to huge pages, with all the stuff needed > for it like moving around userspace pages to compact memory and make > huge page allocation easier. I think these days it is alot easier > to allocate 2M of continuous physical memory than it used to be a > few years ago. At least on linux, dunno about windows. > > When allocating stuff at boot time (say qxl kms driver) allocating > even larger chunks shouldn't be a big issue. And having a single > big guest memory chunk, then register that as qxl memory slot is > what works best with the existing interfaces I guess. Right, this would work. I was trying to avoid claiming a large chunk up front. I was also trying to avoid having our own allocator, although I think that's not really a problem (can be replaced with an in kernel allocator probably). > > 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? > >So I would like to have the guest use a regular > >allocator, generating for instance two sequential pages in virtual > >memory that are scattered in physical memory. Those two physical > >guest page addresses (gp1 and gp2) correspond to two host virtual > >memory addresses (hv1, hv2). I would now like to provide to > >spice-server a single virtual address p that maps to those two pages > >in sequence. > > Playing mapping tricks like this doesn't come for free. When doing > it this way we probaby still want to register a big chunk of memory > as qxl memory slot so we have the mapping cost only once, not for > each and every surface we create and destroy. > > cheers, > Gerd > > _______________________________________________ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel