Re: [Xen-devel] [RFC] Xen Virtual Framebuffer

[Anthony Liguori <aliguori@xxxxxxxxxx>]

Gerd Knorr wrote:

> Anthony Liguori wrote:
>
> > Now that's 3.0.0's out, I thought it would be a good time to bring up 
> > the topic of framebuffer virtualization.
> > I threw together a proof-of-concept over the weekend of a simple 
> > virtual framebuffer/keyboard/mouse.  The basic design is have a 
> > vmalloc()'d buffer in the guest exposed as /dev/fb0 and mmap()'d in 
> > dom0.  There's also a simple message system for keyboard/mouse events.
>
> Browsed through the code, looked at the wiki page now ...
Excellent, I actually have made some major updates but not posted the 
bundle yet.
> First, I've hacked up something very simliar for user-mode-linux, 
> patches are at http://www.suse.de/~kraxel/uml/patches/2.6.15-rc5/, you 
> might want to have a look and steel some ideas (unless you already did).
Excellent, I'll check it out.

> Note that the input system got some sysfs-related changes recently, so 
> the patches really work on very latest kernels only.
> Some more comments:
>
>  * why do you put the mfn and evtchn into the start page?  IMHO that
>    should be handled by xenstore, like it is done for virtual network
>    and disk.
xenstore is not available at start-of-day.  This is why the console 
doesn't use it.  I'm not tied to using the start_info_t though--just 
figured the same arguement could be made for the framebuffer as the console.
>  * I would create two different input devices for mouse/keyboard
>    (although strictly seen it isn't really needed) to avoid confusing
>    userspace apps.
That's what I'm doing right now.  The first drop of the code was a bit 
of a mess wrt how the ring queue was used.
>  * I would simply reuse the input event struct from
>    include/linux/input.h for dom0 -> domU input event delivery
>    instead of creating something new.
Is this too Linux specific though?  I could just copy the structure.

>  * i18n keyboard is really tricky (that is a huge mess in vmx btw).
>    I think the only sane approach is to let the guest (domU) do
>    all the i18n handling and try to avoid doing any key mapping
>    in the host (dom0).  If you have *two* instances (both host
>    and guest) doing keyboard mapping and both not even knowing
>    what the other one is doing you have absolutely no chance to
>    get it right ...
How would you imagine this working?  I'll be getting X11 events in dom0 
so would you just pass them to domU and let it do the mapping?  I know 
QEmu has to use keyboard maps depending on locality.  We wouldn't push 
that into the domU kernel right?
i18n is hard and the thing I really don't know how to do right :-)  Help 
here is greatly appreciated.
> Keeping track of the in-kernel screen changes (fbcon) is easy, 
> tracking userspace is more difficuilt but doable, the uml framebuffer 
> driver does that by watching page faults: The no_page handler maps the 
> page and marks it "dirty", the update function does zap_pte_range to 
> kill the mappings so the no_page handler is called on the next update 
> again.
Yes, the latest code just implements all the 2d ops and passes a message 
through the framebuffer ring queue for updates.  VNC in console mode is 
quite snappy.
I'll take a look at the uml framebuffer to see how it handles page 
faults.  I was thinking of something similiar but didn't know how to 
approach it.
The latest Xen-code is at 
http://www.cs.utexas.edu/users/aliguori/vfb-20051216.bundle
Thanks Gerd!

Regards,

Anthony Liguori

> cheers,
>   Gerd

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