[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: Linux Stubdom Problem

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.