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 limi
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 st
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 m
On 10/02/2011 03:24 PM, Alon Levy wrote:
Hi,
I'm trying to acheive the $subject. Some background: currently spice relies
on a preallocated pci bar for both surfaces and for VGA framebuffer + commands.
I have been trying to get rid of the surfaces bar. To do that I allocate memory
in the gue
On Sun, Oct 02, 2011 at 03:24:36PM +0200, Alon Levy wrote:
> Hi,
>
Converting qemu's ram allocation to a mmap and using remap_file_pages seems
like it could work. Any ideas why it wouldn't?
Alon
> I'm trying to acheive the $subject. Some background: currently spice relies
> on a preallocated
Hi,
I'm trying to acheive the $subject. Some background: currently spice relies on
a preallocated pci bar for both surfaces and for VGA framebuffer + commands. I
have been trying to get rid of the surfaces bar. To do that I allocate memory
in the guest and then translate it for spice-server co
