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

[Jon Smirl <jonsmirl@xxxxxxxxx>]

On 12/16/05, Jacob Gorm Hansen <jacobg@xxxxxxx> wrote:
> On 12/11/05, Jon Smirl <jonsmirl@xxxxxxxxx> wrote:
>
> > You don't have to run the X server in dom0. You can run it in any
> > domain that has sole control of the graphics hardware.  The core
> > problem is that only one domain can have control of the video
> > hardware, there is no realistic way to virtualize a 3D engine.
>
> Even if it is impossible, I am currently attempting to do just that.
> At http://www.diku.dk/~jacobg/gfx you can see a screen shot of 3 Xen
> VM's displaying hardware-accelerated OpenGL to a shared server in
> dom0.

You can virtualize a single vendor's card. You can't really virtualize
3D in general because the cards are so different, there is no common
3D interface to virtualize. If you are going to design a common
virtual 3D interface you might as well use the exiting OpenGL/GLX
protocol rather than design something new. You'll find that GLX is
more communications efficient than virtualizing at the low level.

For example on Linux all of the 3D drivers use the DRM interface. But
the commands sent to the DRM interface are completely different for
each vendor's hardware. dom0 would be forced into decoding vendor
specific commands to stop a user DOM from moving the scanout buffer or
changing the mode. The Linux DRM code does contain a command verifier
which would help in decoding the packets. Another big, complex problem
is that the 3D hardware uses AGP space and DMA. These will have to be
virtualized too.

Another approach would be to use the concepts from Linux direct
rendering and to apply them to the set of VMs. With direct rendering
all of the domains are allowed direct access to the video hardware and
a sharing protocol is provided. In this scheme there is shared memory
between all of the VMs. The shared memory holds the DRM lock and video
memory management data. Each of the VMs would direct render into a
non-visible framebuffer. A master domain would then run composite and
build the screen. You still have to virtualize DMA and AGP. This isn't
really a virtual device, it is a shared device. With virtual devices a
misbehaving domain can't take down the device, in this model a
misbehaving domain can crash the device for all other domains.

> best regards,
> Jacob
>

--
Jon Smirl
jonsmirl@xxxxxxxxx

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