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-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel
