Intel Q35/Q45 fb driver?

McDonald, Michael-p7438c Michael.McDonald at gdc4s.com
Wed Oct 7 10:36:53 PDT 2009


> -----Original Message-----
> From: Adam Jackson [mailto:ajax at nwnk.net] 
> Sent: Wednesday, October 07, 2009 8:04 AM
> To: McDonald, Michael-p7438c
> Cc: xorg at lists.freedesktop.org
> Subject: RE: Intel Q35/Q45 fb driver?
> 
> On Tue, 2009-10-06 at 14:04 -0700, McDonald, Michael-p7438c wrote:
> > > > > Which is pretty dire.  You could just run the app in the vm 
> > > > > but display on the host's X server
> > > > 
> > > > Nope, that would violate security requirements for separation.
> > > 
> > > Then I have trouble understanding how a framebuffer driver 
> > > would make it any better.
> > 
> > The frame buffer driver has nothing to do with security. It is hoped
> > that it will improve performance. Having multiple single 
> level shared
> > memory regions, one per guest, is the core of the security model.
> 
> I don't see how it would improve performance either.  Which memcpy
> would it let you elide?

Currently, the pixels are copied 3 times using XPutImage:

shared memory -> kernel
                 kernel -> Xorg
                           Xorg -> frame buffer

Using MIT SHM extension requires 2 copies (memcpy, XShmPutImage):

shared memory -> MITSHM
                 MITSHM -> frame buffer

Being able to mmap the frame buffer directly reduces it to 1 copy
(XShmPutImage):

shared memory -> frame buffer

Modifying MITSHM to use mmap also reduces it to 1 copy as we can then
mmap our shared memory regions directly into the X server. This is
probably what we'll end up doing (it's implemented and just waiting for
testing). But using the X server still creates extra overhead due to its
size. Since all we're doing is bitblits, the majority of X functionality
is unused.

Mike McDonald





More information about the xorg mailing list