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