|   | 
      | 
  
  
      | 
      | 
  
 
     | 
    | 
  
  
     | 
    | 
  
  
    |   | 
      | 
  
  
    | 
         
xen-devel
[Xen-devel] Re: Linux Stubdom Problem
 
| 
To:  | 
Jiageng Yu <yujiageng734@xxxxxxxxx> | 
 
| 
Subject:  | 
[Xen-devel] Re: Linux Stubdom Problem | 
 
| 
From:  | 
Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> | 
 
| 
Date:  | 
Tue, 23 Aug 2011 15:38:59 +0100 | 
 
| 
Cc:  | 
"Xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>,	Keir Fraser <keir@xxxxxxx>,	Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>,	"tim@xxxxxxx" <tim@xxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>,	Anthony PERARD <anthony.perard@xxxxxxxxx>,	Samuel Thibault <samuel.thibault@xxxxxxxxxxxx> | 
 
| 
Delivery-date:  | 
Tue, 23 Aug 2011 07:32:48 -0700 | 
 
| 
Envelope-to:  | 
www-data@xxxxxxxxxxxxxxxxxxx | 
 
| 
In-reply-to:  | 
<CAJ0pt14PFe4wS6rANNKBk7SeFo62WC2XvtY+umTax9MEV2FuEA@xxxxxxxxxxxxxx> | 
 
| 
List-help:  | 
<mailto:xen-devel-request@lists.xensource.com?subject=help> | 
 
| 
List-id:  | 
Xen developer discussion <xen-devel.lists.xensource.com> | 
 
| 
List-post:  | 
<mailto:xen-devel@lists.xensource.com> | 
 
| 
List-subscribe:  | 
<http://lists.xensource.com/mailman/listinfo/xen-devel>,	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe> | 
 
| 
List-unsubscribe:  | 
<http://lists.xensource.com/mailman/listinfo/xen-devel>,	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> | 
 
| 
References:  | 
<CAJ0pt14RBmT+bCGhU6szMW4Aje-mBQ-WVR8Vb7wOLefgauatbA@xxxxxxxxxxxxxx>	<CAJ0pt175GrngJTxnvx0GRf1RvmXe_JAMxBch+SprKOArNx42ng@xxxxxxxxxxxxxx>	<alpine.DEB.2.00.1107281928020.12963@kaball-desktop>	<CAJ0pt146Te2hCFpxCdwU518HpwRuGHiUj7sSkVOU75YLpoXSBw@xxxxxxxxxxxxxx>	<alpine.DEB.2.00.1107291601070.12963@kaball-desktop>	<CAJ0pt15t_7==0rX9qEHyDMBRWUgfpMyLCmP0yBJsZg410FoutA@xxxxxxxxxxxxxx>	<alpine.DEB.2.00.1107291617130.12963@kaball-desktop>	<CAJ0pt15MVvw5_rJ_xFxR6aQpRYtTWFmR0OHJ54wuXSE+7hNkGQ@xxxxxxxxxxxxxx>	<alpine.DEB.2.00.1107291628000.12963@kaball-desktop>	<CAJ0pt155eqcyUwd-m--m3n+t-hLYixe+xA8J5MWgEWj58+o_Gw@xxxxxxxxxxxxxx>	<CAJ0pt14OXshWn5NQ3JSfqRNdHkWMyhKWC0OwMixu9Xmk0b1oqw@xxxxxxxxxxxxxx>	<alpine.DEB.2.00.1108190027450.12963@kaball-desktop>	<CAJ0pt16CLqt+bHUwvO_V=c39CqN4Y4BCgbcSW26wik4hFTHq_g@xxxxxxxxxxxxxx>	<alpine.DEB.2.00.1108221834340.12963@kaball-desktop>	<CAJ0pt14PFe4wS6rANNKBk7SeFo62WC2XvtY+umTax9MEV2FuEA@xxxxxxxxxxxxxx> | 
 
| 
Sender:  | 
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx | 
 
| 
User-agent:  | 
Alpine 2.00 (DEB 1167 2008-08-23) | 
 
 
 
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
 |   
 
 | 
    | 
  
  
    |   | 
    |