On Mon, 15 Aug 2011, Jiageng Yu wrote:
> Hi Stefano,
>
> In the linux-pv xenfbfront driver, the vram is allocated by:
> xenfb_probe()
> ->info->fb = vmalloc(fb_size);
>
> In the linux-stubdom, the memory areas: (info->fb,
> info->fb+fb_size) in linux-pv kernel, (s->vram_offset,
> s->vram_offset+VGA_RAM_SIZE) in vga_common_init function,
> (s->vram_ptr, s->vram_ptr+VGA_RAM_SIZE) in stubdom. These memory areas
> should be mapped into the same machine memory region.
>
> But the (info->fb, info->fb+fb_size) in linux-pv kernel is
> allocated independently. I have two optional plans to slove the
> problem.
>
> 1. Modify linux-pv kernel.
> This plan is more closer to the minios stubdom. First, I delay the
> initial process of xenfbfront driver until qemu allocates s->vram_ptr.
> Then, I set info->fb = s->vram_ptr.
>
> 2. Modify libxc.
> The s->vram_ptr is generated by mmap() function in
> linux_privcmd_map_foreign_bulk(). Maybe I could replace the return
> value of mmap() with the info->fb, which is obtained from xenstore.
you would also need to modify qemu_ram_alloc to make sure the same pages
are remapped into the guest as videoram
> Can these plans solve the problem? Or there is the better one?
I think it is best to keep the memory allocation in xenfbfront as it is
and find a way to map the pages in qemu. Isn't possible to use a mmap on
the fbdev device to obtain a mapping of the vmalloc'ed area into qemu?
Once we have mapped the pages into qemu address space it is just a
matter of using them as videoram. Otherwise you would have timing
issues because qemu is probably going to start after xenfbfront has
already allocated the buffer and enstablished a connection with the
backend.
In any case why don't you try running a guest without a video card (the
qemu command line option for that is -vga none or -nographic) and see if
everything else works?
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home