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

[Xen-devel] Re: Linux Stubdom Problem



On Tue, 23 Aug 2011, Jiageng Yu wrote:
> > I don't like the stubdom_vga_init approach: in general it is a good idea
> > to avoid state machines unless necessary.
> > I would implement a new function called xen_vga_ram_map in xen-all.c
> > that mmaps the xen_fbfront buffer and uses the new ioctl to
> > map the buffer into the guest.
> > xen_vga_ram_map should be called instead of xen_ram_alloc by
> > qemu_ram_alloc_from_ptr if name == "vga.vram".
> >
> 
> I have question here. I think xen_vga_ram_map() is used to instead of
> xc_map_foreign_bulk() which maps hvm guest's vram.
> 
> vga_common_init
>     -->qemu_get_ram_ptr
>              -->xen_map_cache
>                      -->xen_remap_bucket
>                                -->xc_map_foreign_bulk
> 
> The xen_ram_alloc() calls xc_domain_populate_physmap_exact() to
> increase the physical memory of hvm guest. And the increased physical
> memory becomes hvm guest's vram.
> 
> For the xen_remap_bucket(), there is no "vga.vram" input parameter. So
> we need the notification mechanism to invoke xen_vga_ram_map().

This is how I would do it:

vga_common_init
    -> qemu_ram_alloc
        -> qemu_ram_alloc_from_ptr
            -> xen_vga_ram_map (instead of xen_ram_alloc)
               the function also adds a locked mapcache entry that maps 
               offset to the mmap'ed framebuffer in qemu address space
    -> qemu_get_ram_ptr
        -> xen_map_cache should automatically return the mmap'ed
           framebuffer address thanks to the mapcache entry added by
           xen_vga_ram_map


Another problem is going to surface when cirrus_vga is going to try to
move the framebuffer (see cirrus_pci_lfb_map).
The xen specific function that ends up being called in this case is
xen_all.c:xen_add_to_physmap, we need to change it to call the new ioctl
rather then xc_domain_add_to_physmap.



> > Another suggestion: before starting to write any new lines of code, I
> > would make sure that mmaping the /dev/fb device actually works correctly.
> > For debugging purposes you can try to modify fbdev_init and write
> > something to the framebuffer right after the mmap, to see if the new
> > pattern is displayed correctly on the screen.
> >
> 
> I have tested the xen_fbfront driver in linux stubdom. As shown in
> attached file, I could print a small colored region.

Good!
Is everything working without a graphic card in the guest?
If so, we are really missing just the videoram bit.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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