[RFC] Xen Virtual Framebuffer

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[RFC] Xen Virtual Framebuffer

Anthony Liguori
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.

The first frontend is a GTK widget with python bindings (so it can
easily be embedded in a larger management app) and a small python app.  
Right now, the VT system seems to work fine and X starts quite happily
(using the fbdev driver).  Clicking in the app captures the
mouse/keyboard and ctrl+alt will release the capture.

There's a readme and an hg bundle in the tarball below that explains how
to set things up.

Some interesting topics in this area are acceleration, whether we should
implement our own X driver (or just enhance the fbdev driver since it
uses no acceleration right now), and how to properly expose it over
something like VNC.

As always, feedback is greatly appreciated.

http://www.cs.utexas.edu/users/aliguori/xen-vfb-20051205.tar.gz

Regards,

Anthony Liguori

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Xen Virtual Framebuffer

Anthony Liguori
I've made a page in the Wiki with more details:

http://wiki.xensource.com/xenwiki/VirtualFramebuffer

Regards,

Anthony Liguori

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.
>
> The first frontend is a GTK widget with python bindings (so it can
> easily be embedded in a larger management app) and a small python
> app.  Right now, the VT system seems to work fine and X starts quite
> happily (using the fbdev driver).  Clicking in the app captures the
> mouse/keyboard and ctrl+alt will release the capture.
>
> There's a readme and an hg bundle in the tarball below that explains
> how to set things up.
>
> Some interesting topics in this area are acceleration, whether we
> should implement our own X driver (or just enhance the fbdev driver
> since it uses no acceleration right now), and how to properly expose
> it over something like VNC.
>
> As always, feedback is greatly appreciated.
>
> http://www.cs.utexas.edu/users/aliguori/xen-vfb-20051205.tar.gz
>
> Regards,
>
> Anthony Liguori
>
> _______________________________________________
> Xen-devel mailing list
> [hidden email]
> http://lists.xensource.com/xen-devel
>


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Xen Virtual Framebuffer

Jon Smirl
I haven't tried playing with X and Xen, but why doesn't it work to
just treat the multiple domains like a network? You run X in dom0 and
give it full access to the video hardware. Then you ssh into each
domain and start X apps, just like you do when using X remotely.
OpenGL will even work this way and be accelerated (as soon as X fixes
indirect acceleration). This model should let you get apps up from
each domain simultaneously on the X display in dom0.

--
Jon Smirl
[hidden email]

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|

RE: [RFC] Xen Virtual Framebuffer

James Harper
In reply to this post by Anthony Liguori
Some things just work better when you can enable shared memory
extensions under X, which obviously can't be done over the network.

Also, X isn't the only thing that can make use of a framebuffer.

James

> -----Original Message-----
> From: [hidden email] [mailto:xen-devel-
> [hidden email]] On Behalf Of Jon Smirl
> Sent: Tuesday, 6 December 2005 11:36
> To: Anthony Liguori
> Cc: xen-devel
> Subject: Re: [Xen-devel] [RFC] Xen Virtual Framebuffer
>
> I haven't tried playing with X and Xen, but why doesn't it work to
> just treat the multiple domains like a network? You run X in dom0 and
> give it full access to the video hardware. Then you ssh into each
> domain and start X apps, just like you do when using X remotely.
> OpenGL will even work this way and be accelerated (as soon as X fixes
> indirect acceleration). This model should let you get apps up from
> each domain simultaneously on the X display in dom0.
>
> --
> Jon Smirl
> [hidden email]
>
> _______________________________________________
> Xen-devel mailing list
> [hidden email]
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Xen Virtual Framebuffer

Mark Williamson-9
In reply to this post by Anthony Liguori
Wow!  That was fast work ;-)

Sounds like really good stuff. Is there any chance of a couple of
screenshots?

Have you had a chance to check out comparable X.org drivers? How hairy are
they to put together? I agree it seems nicest (in terms of compatibility
with Xen-unaware X servers) to use a kernel-based framebuffer as a basis
for things (as opposed to having X talk to the virtual display directly).
It also allows us automagic compatibility with toolkits and apps that can
render to the framebuffer directly.

Side note: it'd be really nice to be able to have an option to export the
guest framebuffer display over VNC using libvncserver. The intent would be
to allow management software on another node to access domain consoles,
without needing the domain to mess about running VNC (or indeed, having a
working network setup). I'm sure you've thought of that, though ;-)

Other side note: it'd be really neat to be able to support copy-and-paste
operations from text mode consoles to other windows in dom0. Does the
kernel have hooks in the right places to make this workable?

Cheers,
Mark

On Dec 5 2005, 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.
>
>The first frontend is a GTK widget with python bindings (so it can
>easily be embedded in a larger management app) and a small python app.  
>Right now, the VT system seems to work fine and X starts quite happily
>(using the fbdev driver).  Clicking in the app captures the
>mouse/keyboard and ctrl+alt will release the capture.
>
>There's a readme and an hg bundle in the tarball below that explains how
>to set things up.
>
>Some interesting topics in this area are acceleration, whether we should
>implement our own X driver (or just enhance the fbdev driver since it
>uses no acceleration right now), and how to properly expose it over
>something like VNC.
>
>As always, feedback is greatly appreciated.
>
>http://www.cs.utexas.edu/users/aliguori/xen-vfb-20051205.tar.gz
>
>Regards,
>
>Anthony Liguori
>
>_______________________________________________
>Xen-devel mailing list
>[hidden email]
>http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|

RE: [RFC] Xen Virtual Framebuffer

Mark Williamson-9
In reply to this post by James Harper
And as another also: a big usability benefit of having the framebuffer is
that users don't have to have a working network or install any extra
software. It's just a transparency thing; you don't really *need* it but it
makes domUs behave more like "proper" machines.

It should also give better performance, as James mentioned. Eventually,
it'd be nice to support accelerated OpenGL in domUs but that may be some
way off.

Cheers,
Mark

On Dec 6 2005, James Harper wrote:

>Some things just work better when you can enable shared memory
>extensions under X, which obviously can't be done over the network.
>
>Also, X isn't the only thing that can make use of a framebuffer.
>
>James
>
>> -----Original Message-----
>> From: [hidden email] [mailto:xen-devel-
>> [hidden email]] On Behalf Of Jon Smirl
>> Sent: Tuesday, 6 December 2005 11:36
>> To: Anthony Liguori
>> Cc: xen-devel
>> Subject: Re: [Xen-devel] [RFC] Xen Virtual Framebuffer
>>
>> I haven't tried playing with X and Xen, but why doesn't it work to
>> just treat the multiple domains like a network? You run X in dom0 and
>> give it full access to the video hardware. Then you ssh into each
>> domain and start X apps, just like you do when using X remotely.
>> OpenGL will even work this way and be accelerated (as soon as X fixes
>> indirect acceleration). This model should let you get apps up from
>> each domain simultaneously on the X display in dom0.
>>
>> --
>> Jon Smirl
>> [hidden email]
>>
>> _______________________________________________
>> Xen-devel mailing list
>> [hidden email]
>> http://lists.xensource.com/xen-devel
>
>
>_______________________________________________
>Xen-devel mailing list
>[hidden email]
>http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Xen Virtual Framebuffer

Anthony Liguori
In reply to this post by Jon Smirl
Hi Jon,

The basic problem is running something like gdm or nautilus which want
to own the root X window.  You'd have to use something like Xnest.  It
doesn't help much with VT switching either which would be a really nice
feature to has.

However, using remote X is a good option for a number of use-cases so
it's certainly appropriate for certain environments.

Regards,

Anthony Liguori

Jon Smirl wrote:

>I haven't tried playing with X and Xen, but why doesn't it work to
>just treat the multiple domains like a network? You run X in dom0 and
>give it full access to the video hardware. Then you ssh into each
>domain and start X apps, just like you do when using X remotely.
>OpenGL will even work this way and be accelerated (as soon as X fixes
>indirect acceleration). This model should let you get apps up from
>each domain simultaneously on the X display in dom0.
>
>--
>Jon Smirl
>[hidden email]
>
>  
>


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Xen Virtual Framebuffer

Jon Smirl
In reply to this post by Mark Williamson-9
On 06 Dec 2005 00:53:14 +0000, M.A. Williamson <[hidden email]> wrote:
> And as another also: a big usability benefit of having the framebuffer is
> that users don't have to have a working network or install any extra
> software. It's just a transparency thing; you don't really *need* it but it
> makes domUs behave more like "proper" machines.

You don't need a network outside of the box; you just treat all of the
domains as being wired together with a virtual network inside of the
box.  X already uses Unix domain sockets to talk between apps and the
X server. I would expect a virtualized network running inside the box
to have about the same performance as Unix domain sockets. The X
server already support this socket model today, no new code needs to
be written, Xen just needs to provide the internal virtual network.

> It should also give better performance, as James mentioned. Eventually,
> it'd be nice to support accelerated OpenGL in domUs but that may be some
> way off.

Virtual framebuffer is not going to give you better performance than
the X socket system. I wrote this paper a while ago, it should give
you a good feel of the complexities involved.
http://dri.freedesktop.org/~jonsmirl/graphics.html

>
> Cheers,
> Mark
>
> On Dec 6 2005, James Harper wrote:
>
> >Some things just work better when you can enable shared memory
> >extensions under X, which obviously can't be done over the network.
> >
> >Also, X isn't the only thing that can make use of a framebuffer.
> >
> >James
> >
> >> -----Original Message-----
> >> From: [hidden email] [mailto:xen-devel-
> >> [hidden email]] On Behalf Of Jon Smirl
> >> Sent: Tuesday, 6 December 2005 11:36
> >> To: Anthony Liguori
> >> Cc: xen-devel
> >> Subject: Re: [Xen-devel] [RFC] Xen Virtual Framebuffer
> >>
> >> I haven't tried playing with X and Xen, but why doesn't it work to
> >> just treat the multiple domains like a network? You run X in dom0 and
> >> give it full access to the video hardware. Then you ssh into each
> >> domain and start X apps, just like you do when using X remotely.
> >> OpenGL will even work this way and be accelerated (as soon as X fixes
> >> indirect acceleration). This model should let you get apps up from
> >> each domain simultaneously on the X display in dom0.
> >>
> >> --
> >> Jon Smirl
> >> [hidden email]
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> [hidden email]
> >> http://lists.xensource.com/xen-devel
> >
> >
> >_______________________________________________
> >Xen-devel mailing list
> >[hidden email]
> >http://lists.xensource.com/xen-devel
> >
>


--
Jon Smirl
[hidden email]

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Xen Virtual Framebuffer

Jon Smirl
In reply to this post by James Harper
On 12/5/05, James Harper <[hidden email]> wrote:
> Some things just work better when you can enable shared memory
> extensions under X, which obviously can't be done over the network.
>
> Also, X isn't the only thing that can make use of a framebuffer.

What is an example of something that uses framebuffer?

Console is not a good example since that is effectively addressed by
using remote xterms.

>
> James

--
Jon Smirl
[hidden email]

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Xen Virtual Framebuffer

Anthony Liguori
In reply to this post by Mark Williamson-9
M.A. Williamson wrote:

> Wow!  That was fast work ;-)

Linux rocks :-)  The fb driver infrastructure is really easy to work with.

> Sounds like really good stuff. Is there any chance of a couple of
> screenshots?

Yeah, I can post some (I'll link on the wiki page) tomorrow as I forgot
to re-enable VNC on my dev machine so I have to wait to head back in the
office.  It looks a lot like VT or Qemu right now as you can imagine :-)

> Have you had a chance to check out comparable X.org drivers? How hairy
> are they to put together? I agree it seems nicest (in terms of
> compatibility with Xen-unaware X servers) to use a kernel-based
> framebuffer as a basis for things (as opposed to having X talk to the
> virtual display directly). It also allows us automagic compatibility
> with toolkits and apps that can render to the framebuffer directly.

What's nice is that the fbdev device maps the memory directly to
userspace, so you don't take a hit at all by going through the kernel
interface.  My current line of thinking is to use an fb device with
special device-specific ioctls for the couple non-standard accelerations
we could implement.

The X.org code doesn't look so bad.  Interestingly, VMware has a driver
in the X.org tree so I don't think we'll have a problem just working
with those guys to get our own driver :-)

> Side note: it'd be really nice to be able to have an option to export
> the guest framebuffer display over VNC using libvncserver. The intent
> would be to allow management software on another node to access domain
> consoles, without needing the domain to mess about running VNC (or
> indeed, having a working network setup). I'm sure you've thought of
> that, though ;-)

Absolutely.  libvncserver is not a pleasant library but a reasonable
place to start.  We really need to implement a few accelerations first
before VNC is a reasonable option (at least copyrect) since otherwise
we'll have to do a lot of computation to figure out what portions of the
screen have changed.

> Other side note: it'd be really neat to be able to support
> copy-and-paste operations from text mode consoles to other windows in
> dom0. Does the kernel have hooks in the right places to make this
> workable?

I'm not sure.  I think there may be some clever approachs to it.  If
nothing else, some patches to gpm could achieve the desired effect.  
copy/paste would be an awesome feature to have so I'm definitely
interested in making it work.

The same is true for drag and drop :-)  There are a lot of cool things
we can do...

Regards,

Anthony Liguori

> Cheers,
> Mark
>
> On Dec 5 2005, 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.
>>
>> The first frontend is a GTK widget with python bindings (so it can
>> easily be embedded in a larger management app) and a small python
>> app.  Right now, the VT system seems to work fine and X starts quite
>> happily (using the fbdev driver).  Clicking in the app captures the
>> mouse/keyboard and ctrl+alt will release the capture.
>>
>> There's a readme and an hg bundle in the tarball below that explains
>> how to set things up.
>>
>> Some interesting topics in this area are acceleration, whether we
>> should implement our own X driver (or just enhance the fbdev driver
>> since it uses no acceleration right now), and how to properly expose
>> it over something like VNC.
>>
>> As always, feedback is greatly appreciated.
>>
>> http://www.cs.utexas.edu/users/aliguori/xen-vfb-20051205.tar.gz
>>
>> Regards,
>>
>> Anthony Liguori
>>
>> _______________________________________________
>> Xen-devel mailing list
>> [hidden email]
>> http://lists.xensource.com/xen-devel
>>
>


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Xen Virtual Framebuffer

Jon Smirl
In reply to this post by Anthony Liguori
On 12/5/05, Anthony Liguori <[hidden email]> wrote:
> Hi Jon,
>
> The basic problem is running something like gdm or nautilus which want
> to own the root X window.  You'd have to use something like Xnest.  It
> doesn't help much with VT switching either which would be a really nice
> feature to has.

Xnest is the best solution for multiple root windows. With virtual
framebuffers you are just building Xnest again via a different
mechanism. Xnest has the advantage that you can use hardware
acceleration from the X server in dom0.

> However, using remote X is a good option for a number of use-cases so
> it's certainly appropriate for certain environments.
>
> Regards,
>
> Anthony Liguori
>
> Jon Smirl wrote:
>
> >I haven't tried playing with X and Xen, but why doesn't it work to
> >just treat the multiple domains like a network? You run X in dom0 and
> >give it full access to the video hardware. Then you ssh into each
> >domain and start X apps, just like you do when using X remotely.
> >OpenGL will even work this way and be accelerated (as soon as X fixes
> >indirect acceleration). This model should let you get apps up from
> >each domain simultaneously on the X display in dom0.
> >
> >--
> >Jon Smirl
> >[hidden email]
> >
> >
> >
>
>


--
Jon Smirl
[hidden email]

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Xen Virtual Framebuffer

Anthony Liguori
Jon Smirl wrote:

>On 12/5/05, Anthony Liguori <[hidden email]> wrote:
>  
>
>>Hi Jon,
>>
>>The basic problem is running something like gdm or nautilus which want
>>to own the root X window.  You'd have to use something like Xnest.  It
>>doesn't help much with VT switching either which would be a really nice
>>feature to has.
>>    
>>
>
>Xnest is the best solution for multiple root windows. With virtual
>framebuffers you are just building Xnest again via a different
>mechanism. Xnest has the advantage that you can use hardware
>acceleration from the X server in dom0.
>  
>
I like Xnest quite a lot.  We need something that's available when X
isn't though (for the VT console for instance).

You certainly don't have to run X on /dev/fb0.  It's mostly to make
text-mode and distro installation a whole lot more user friendly.

Regards,

Anthony Liguori

>>However, using remote X is a good option for a number of use-cases so
>>it's certainly appropriate for certain environments.
>>
>>Regards,
>>
>>Anthony Liguori
>>
>>Jon Smirl wrote:
>>
>>    
>>
>>>I haven't tried playing with X and Xen, but why doesn't it work to
>>>just treat the multiple domains like a network? You run X in dom0 and
>>>give it full access to the video hardware. Then you ssh into each
>>>domain and start X apps, just like you do when using X remotely.
>>>OpenGL will even work this way and be accelerated (as soon as X fixes
>>>indirect acceleration). This model should let you get apps up from
>>>each domain simultaneously on the X display in dom0.
>>>
>>>--
>>>Jon Smirl
>>>[hidden email]
>>>
>>>
>>>
>>>      
>>>
>>    
>>
>
>
>--
>Jon Smirl
>[hidden email]
>
>  
>


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Xen Virtual Framebuffer

Jon Smirl
On 12/5/05, Anthony Liguori <[hidden email]> wrote:
> I like Xnest quite a lot.  We need something that's available when X
> isn't though (for the VT console for instance).
>
> You certainly don't have to run X on /dev/fb0.  It's mostly to make
> text-mode and distro installation a whole lot more user friendly.

Can't distro install into a domain be handled on a virtual serial line
and Linux terminal emulation? This seems like a lot of work to go
through to get something like Redhat's graphical boot working.

>
> Regards,
>
> Anthony Liguori
>
> >>However, using remote X is a good option for a number of use-cases so
> >>it's certainly appropriate for certain environments.
> >>
> >>Regards,
> >>
> >>Anthony Liguori
> >>
> >>Jon Smirl wrote:
> >>
> >>
> >>
> >>>I haven't tried playing with X and Xen, but why doesn't it work to
> >>>just treat the multiple domains like a network? You run X in dom0 and
> >>>give it full access to the video hardware. Then you ssh into each
> >>>domain and start X apps, just like you do when using X remotely.
> >>>OpenGL will even work this way and be accelerated (as soon as X fixes
> >>>indirect acceleration). This model should let you get apps up from
> >>>each domain simultaneously on the X display in dom0.
> >>>
> >>>--
> >>>Jon Smirl
> >>>[hidden email]
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >--
> >Jon Smirl
> >[hidden email]
> >
> >
> >
>
>


--
Jon Smirl
[hidden email]

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Xen Virtual Framebuffer

Anthony Liguori
Jon Smirl wrote:

>On 12/5/05, Anthony Liguori <[hidden email]> wrote:
>  
>
>>I like Xnest quite a lot.  We need something that's available when X
>>isn't though (for the VT console for instance).
>>
>>You certainly don't have to run X on /dev/fb0.  It's mostly to make
>>text-mode and distro installation a whole lot more user friendly.
>>    
>>
>
>Can't distro install into a domain be handled on a virtual serial line
>and Linux terminal emulation? This seems like a lot of work to go
>through to get something like Redhat's graphical boot working.
>  
>
I added a section to the Wiki page for discussion of various approachs
and the pros/cons.  Feel free to extend this information.

So far, the framebuffer has not been all that much code (only a few
hundred lines) so I think the benefit from the increased usuability is
well worth it.

Thanks for the feedback,

Anthony Liguori

>>Regards,
>>
>>Anthony Liguori
>>
>>    
>>
>>>>However, using remote X is a good option for a number of use-cases so
>>>>it's certainly appropriate for certain environments.
>>>>
>>>>Regards,
>>>>
>>>>Anthony Liguori
>>>>
>>>>Jon Smirl wrote:
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>I haven't tried playing with X and Xen, but why doesn't it work to
>>>>>just treat the multiple domains like a network? You run X in dom0 and
>>>>>give it full access to the video hardware. Then you ssh into each
>>>>>domain and start X apps, just like you do when using X remotely.
>>>>>OpenGL will even work this way and be accelerated (as soon as X fixes
>>>>>indirect acceleration). This model should let you get apps up from
>>>>>each domain simultaneously on the X display in dom0.
>>>>>
>>>>>--
>>>>>Jon Smirl
>>>>>[hidden email]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>        
>>>>
>>>--
>>>Jon Smirl
>>>[hidden email]
>>>
>>>
>>>
>>>      
>>>
>>    
>>
>
>
>--
>Jon Smirl
>[hidden email]
>
>  
>


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Xen Virtual Framebuffer

Jon Smirl
In reply to this post by Anthony Liguori
After thinking about this for a while, wouldn't Xen be better off with
a virtual VGA device instead of a virtual fbdev? The virtual VGA
device will work for other operating systems as well as Linux.
Implementing a VESA BIOS may be better than emulating VGA.
http://www.vesa.org/public/VBE/vbecore3.pdf

I'm not exactly sure how Redhat install boots, but when it first comes
up it has to be using VGA mode or vesafb since it doesn't know what
video hardware the box has. (What does it do if there is no video card
installed? serial line?) After a couple of questions in VGA mode it
quickly starts an X server and goes graphical.

On a server box with only a serial line and no video hardware, the
install has to stay in text mode using terminal emulation.

The problem is when the distro wants to start the X sever and go into
graphics mode. That isn't going to work very well with the Xen model.
You have three choices:
1) Treat it like a server and use the virtual serial line with
terminal emulation
2) virtual VGA - Let it start the xserver and run the xserver on the
virtual VGA device.
3) or create a new install mode where the installer starts a network
device, waits for an ssh connect, and then run a remote X based
installation.

The third mode would be best for Xen but I don't believe an
distribution works that way currently. #3 is a minor change to
existing installers. One problem I see is knowing what address to ssh
into. The address could be sent to the serial console as part of the
boot process. If you want to get fancy implement a new terminal escape
sequence that could be sent down the serial line which will trigger
the ssh connect and run the graphical installer.

--
Jon Smirl
[hidden email]

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Xen Virtual Framebuffer

Mark Williamson-9
In reply to this post by Jon Smirl
>You don't need a network outside of the box; you just treat all of the
>domains as being wired together with a virtual network inside of the
>box.

Sure thing; I'm just expecting users to break their network configuration
with alacrity ;-) Something that's zero-config would be nice to have
available as a baseline.

As a bonus it also gives us the opportunity to support things like QT
Embedded, GTK, elinks, etc when those are configured to render direct to
the framebuffer device. To be fair, these users are likely to be relatively
uncommon.

> X already uses Unix domain sockets to talk between apps and the
>X server. I would expect a virtualized network running inside the box
>to have about the same performance as Unix domain sockets. The X
>server already support this socket model today, no new code needs to
>be written, Xen just needs to provide the internal virtual network.
>
>> It should also give better performance, as James mentioned. Eventually,
>> it'd be nice to support accelerated OpenGL in domUs but that may be some
>> way off.
>
>Virtual framebuffer is not going to give you better performance than
>the X socket system. I wrote this paper a while ago, it should give
>you a good feel of the complexities involved.
>http://dri.freedesktop.org/~jonsmirl/graphics.html

It seems relatively unfortunate to have to transfer data over the internal
network when we could just use framebuffer memory which would be shared
dom0 <-> domU (although I'm not sure if that overhead would actually matter
to us). Surely it'd also be beneficial to enable X<->app shared memory
tricks etc, rather than running over a network socket?

Btw, that paper had been on my "must read" list for a while, thanks for
reminding me. Kudos for your work on Xgl, too bad you weren't supported
more.

Cheers,
Mark

>
>>
>> Cheers,
>> Mark
>>
>> On Dec 6 2005, James Harper wrote:
>>
>> >Some things just work better when you can enable shared memory
>> >extensions under X, which obviously can't be done over the network.
>> >
>> >Also, X isn't the only thing that can make use of a framebuffer.
>> >
>> >James
>> >
>> >> -----Original Message-----
>> >> From: [hidden email] [mailto:xen-devel-
>> >> [hidden email]] On Behalf Of Jon Smirl
>> >> Sent: Tuesday, 6 December 2005 11:36
>> >> To: Anthony Liguori
>> >> Cc: xen-devel
>> >> Subject: Re: [Xen-devel] [RFC] Xen Virtual Framebuffer
>> >>
>> >> I haven't tried playing with X and Xen, but why doesn't it work to
>> >> just treat the multiple domains like a network? You run X in dom0 and
>> >> give it full access to the video hardware. Then you ssh into each
>> >> domain and start X apps, just like you do when using X remotely.
>> >> OpenGL will even work this way and be accelerated (as soon as X fixes
>> >> indirect acceleration). This model should let you get apps up from
>> >> each domain simultaneously on the X display in dom0.
>> >>
>> >> --
>> >> Jon Smirl
>> >> [hidden email]
>> >>
>> >> _______________________________________________
>> >> Xen-devel mailing list
>> >> [hidden email]
>> >> http://lists.xensource.com/xen-devel
>> >
>> >
>> >_______________________________________________
>> >Xen-devel mailing list
>> >[hidden email]
>> >http://lists.xensource.com/xen-devel
>> >
>>
>
>
>--
>Jon Smirl
>[hidden email]
>

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Xen Virtual Framebuffer

Anthony Liguori
In reply to this post by Jon Smirl
Jon Smirl wrote:

>After thinking about this for a while, wouldn't Xen be better off with
>a virtual VGA device instead of a virtual fbdev? The virtual VGA
>device will work for other operating systems as well as Linux.
>Implementing a VESA BIOS may be better than emulating VGA.
>http://www.vesa.org/public/VBE/vbecore3.pdf
>  
>
This is how Qemu does it so it's what we do for VT.  The VMI spec
(VMware paravirtual spec) assumes that you'll be doing device emulation
and calls for an emulated PCI bus.  Xen achieves really good performance
though by avoiding device emulation.  Native speed device emulation is
an active area of research though so this might not always be the case :-)

We don't currently do that in Xen though so it would be a considerable
amount of work to emulate a PCI bus and a VGA device (not to mention an
emu86 to be able to run the BIOS).

Regards,

Anthony Liguori

>--
>Jon Smirl
>[hidden email]
>
>  
>


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Xen Virtual Framebuffer

Jon Smirl
On 12/5/05, Anthony Liguori <[hidden email]> wrote:

> Jon Smirl wrote:
>
> >After thinking about this for a while, wouldn't Xen be better off with
> >a virtual VGA device instead of a virtual fbdev? The virtual VGA
> >device will work for other operating systems as well as Linux.
> >Implementing a VESA BIOS may be better than emulating VGA.
> >http://www.vesa.org/public/VBE/vbecore3.pdf
> >
> >
> This is how Qemu does it so it's what we do for VT.  The VMI spec
> (VMware paravirtual spec) assumes that you'll be doing device emulation
> and calls for an emulated PCI bus.  Xen achieves really good performance
> though by avoiding device emulation.  Native speed device emulation is
> an active area of research though so this might not always be the case :-)
>
> We don't currently do that in Xen though so it would be a considerable
> amount of work to emulate a PCI bus and a VGA device (not to mention an
> emu86 to be able to run the BIOS).

VGA devices don't live on the PCI bus, they are ISA legacy devices at
fixed IO ports/RAM address. But VESA is a better solution than the VGA
device.

Does Xen supply a BIOS into the virtual machine? If so, just implement
the VESA entry points. Most of the Xen-based VESA entry points will do
nothing, but they can't return the not-implemented error. This is very
similar to what you are doing with a virtual fbdev, but the VESA
scheme will work for Windows too. Linux already has a vesafb driver
that will use the entry points you provide.

However, I am assuming that Windows/Linux will fallback to using VESA
calls if they don't find a physical VGA device. There isn't a simple
way to test this since every video card that implements VESA also
implements VGA. If you want to get errors from Linux while it is still
in real mode you need to implement the BIOS INT 10 interface.

--
Jon Smirl
[hidden email]

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|

答复: [RFC] Xen Virtual Framebuffer

Miao Feng
I think this topic must be subject to Para-Virtualized Guest Linux (or some
other os), for unmodified guest os on a VTx box, do you have any suggestion
for graphic acceleration?

And, what if we adjust the qemu-dm to accommodate both Para-dom and VTx-dom?

 

Miao Feng

Star SoftComm(China) Ltd


-----邮件原件-----
发件人: [hidden email]
[mailto:[hidden email]] 代表 Jon Smirl
发送时间: 2005年12月6日 11:13
收件人: Anthony Liguori
抄送: xen-devel; Antonino A. Daplas
主题: Re: [Xen-devel] [RFC] Xen Virtual Framebuffer

On 12/5/05, Anthony Liguori <[hidden email]> wrote:

> Jon Smirl wrote:
>
> >After thinking about this for a while, wouldn't Xen be better off with
> >a virtual VGA device instead of a virtual fbdev? The virtual VGA
> >device will work for other operating systems as well as Linux.
> >Implementing a VESA BIOS may be better than emulating VGA.
> >http://www.vesa.org/public/VBE/vbecore3.pdf
> >
> >
> This is how Qemu does it so it's what we do for VT.  The VMI spec
> (VMware paravirtual spec) assumes that you'll be doing device emulation
> and calls for an emulated PCI bus.  Xen achieves really good performance
> though by avoiding device emulation.  Native speed device emulation is
> an active area of research though so this might not always be the case :-)
>
> We don't currently do that in Xen though so it would be a considerable
> amount of work to emulate a PCI bus and a VGA device (not to mention an
> emu86 to be able to run the BIOS).

VGA devices don't live on the PCI bus, they are ISA legacy devices at
fixed IO ports/RAM address. But VESA is a better solution than the VGA
device.

Does Xen supply a BIOS into the virtual machine? If so, just implement
the VESA entry points. Most of the Xen-based VESA entry points will do
nothing, but they can't return the not-implemented error. This is very
similar to what you are doing with a virtual fbdev, but the VESA
scheme will work for Windows too. Linux already has a vesafb driver
that will use the entry points you provide.

However, I am assuming that Windows/Linux will fallback to using VESA
calls if they don't find a physical VGA device. There isn't a simple
way to test this since every video card that implements VESA also
implements VGA. If you want to get errors from Linux while it is still
in real mode you need to implement the BIOS INT 10 interface.

--
Jon Smirl
[hidden email]

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel




_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|

Re: 答复: [RFC] Xen Virtual Framebuffer

Anthony Liguori
苗枫 wrote:

>I think this topic must be subject to Para-Virtualized Guest Linux (or some
>other os), for unmodified guest os on a VTx box, do you have any suggestion
>for graphic acceleration?
>  
>
You're right, this is PV guest framebuffer virtualization.

There was a discussion recently on #qemu about acceleration. There are
few possibilities. The first would be to use 2d acceleration instead of
emulating in software (the cirrus card has all the standard fill, copy,
etc 2d ops). Then there's the topic of 3d acceleration.

This is a pretty big task and probably something you want to do with a
paravirtual driver. If we had our own X driver, we could implement the
appropriate pass-thru stuff. I don't know enough about Windows internals
to comment intelligently on it.

>And, what if we adjust the qemu-dm to accommodate both Para-dom and VTx-dom?
>  
>
This is something I'm very interested in. Unifying VT/PV management will
definitely be an important usability feature for future versions of Xen.
Haven't though much about it myself though.

Regards,

Anthony Liguori

>
>
>Miao Feng
>
>Star SoftComm(China) Ltd
>
>
>-----邮件原件-----
>发件人: [hidden email]
>[mailto:[hidden email]] 代表 Jon Smirl
>发送时间: 2005年12月6日 11:13
>收件人: Anthony Liguori
>抄送: xen-devel; Antonino A. Daplas
>主题: Re: [Xen-devel] [RFC] Xen Virtual Framebuffer
>
>On 12/5/05, Anthony Liguori <[hidden email]> wrote:
>  
>
>>Jon Smirl wrote:
>>
>>    
>>
>>>After thinking about this for a while, wouldn't Xen be better off with
>>>a virtual VGA device instead of a virtual fbdev? The virtual VGA
>>>device will work for other operating systems as well as Linux.
>>>Implementing a VESA BIOS may be better than emulating VGA.
>>>http://www.vesa.org/public/VBE/vbecore3.pdf
>>>
>>>
>>>      
>>>
>>This is how Qemu does it so it's what we do for VT.  The VMI spec
>>(VMware paravirtual spec) assumes that you'll be doing device emulation
>>and calls for an emulated PCI bus.  Xen achieves really good performance
>>though by avoiding device emulation.  Native speed device emulation is
>>an active area of research though so this might not always be the case :-)
>>
>>We don't currently do that in Xen though so it would be a considerable
>>amount of work to emulate a PCI bus and a VGA device (not to mention an
>>emu86 to be able to run the BIOS).
>>    
>>
>
>VGA devices don't live on the PCI bus, they are ISA legacy devices at
>fixed IO ports/RAM address. But VESA is a better solution than the VGA
>device.
>
>Does Xen supply a BIOS into the virtual machine? If so, just implement
>the VESA entry points. Most of the Xen-based VESA entry points will do
>nothing, but they can't return the not-implemented error. This is very
>similar to what you are doing with a virtual fbdev, but the VESA
>scheme will work for Windows too. Linux already has a vesafb driver
>that will use the entry points you provide.
>
>However, I am assuming that Windows/Linux will fallback to using VESA
>calls if they don't find a physical VGA device. There isn't a simple
>way to test this since every video card that implements VESA also
>implements VGA. If you want to get errors from Linux while it is still
>in real mode you need to implement the BIOS INT 10 interface.
>
>--
>Jon Smirl
>[hidden email]
>
>_______________________________________________
>Xen-devel mailing list
>[hidden email]
>http://lists.xensource.com/xen-devel
>
>
>
>
>  
>


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
12