[Spice-devel] viewing continuous guest virtual memory as continuous in qemu

[Alon Levy]

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