Does Xorg server pin composition buffer's MFNs?

Adam Jackson ajax at
Fri Apr 16 08:41:51 PDT 2010

On Fri, 2010-04-16 at 10:47 +0200, Rafal Wojtczuk wrote:
> On Wed, Apr 14, 2010 at 03:59:39PM -0400, Adam Jackson wrote:
> > I'm assuming by "composition buffer" you mean the thing you're actually
> > scanning out on the display.
> No. I mean the per-window offscreen storage mechanism, activated by 
> XCompositeRedirectSubwindows() function. Referred to as "windows backing
> pixmap" in Apologies if
> I did not make it clear enough.

Window pixmaps are like any other pixmap.  Where they live is entirely
up to the driver.  Unaccelerated drivers keep them in host memory with
malloc().  Accelerated drivers do that sometimes, and then sometimes put
them in video memory.  Remember that you can have more video memory than
you can see through a PCI BAR, so you might not be able to address the
pixmap from the CPU at all.

> Briefly, the goal is to get the location of a composition buffer created by 
> X server running in virtual machine A, and map it in the address space of 
> virtual machine B. Such mapping has to be defined in terms of physical 
> addresses; consequently, it is crucial to make sure that the frames backing a 
> composition buffer do not change in time.

That's not going to do anything useful without some synchronization
work.  Window pixmaps aren't created afresh for each frame.  They're
long-lived.  If you manage to get a pixmap shared between VMs A and B,
there's nothing to stop A from rendering into it while B is reading from

The way compositing managers handle this is by taking an X server grab
while reading out of the window pixmap, which does prevent other client
rendering from happening.  And as soon as you're doing _that_, just
XGetImage the pixels out instead of playing funny MMU games, it'll
probably be faster.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the xorg mailing list