Does Xorg server pin composition buffer's MFNs?

[Adam Jackson]

On Wed, 2010-04-14 at 20:07 +0200, Rafal Wojtczuk wrote:
> Hello,
> A bit of background: apparently under Linux, the mfn (say, physical address) 
> of the frame, that holds an usermode page, can change, unless precautions 
> are made. See http://lists.xensource.com/archives/html/xen-devel/2010-04/msg00514.html
> why it might be an issue in certain virtualized environments.
> 
> Question 1: does X server (running under Linux), allocate the composition 
> buffers in an usual way (using malloc() or similar), or does it do anything 
> fancier in order to make sure the physical address of composition buffers is 
> stable in time ? 
> Question 2: Does ever X server schedule a DMA transaction (to graphics card 
> presumably) from a composition buffer ? (in such case it would make sense to 
> pin its physical pages).

I'm assuming by "composition buffer" you mean the thing you're actually
scanning out on the display.  I'll use the word "framebuffer" for that,
since that's the usual X name for it.

In the absence of an accelerated driver, X doesn't care about the
physical address of the framebuffer at runtime.  Older versions of X
would mmap /dev/mem starting at the physical address of the framebuffer
(as gleaned from the PCI config registers), but after that point we just
write into it by virtual address.  Newer ones do basically the same
thing but on the resource file in sysfs for the PCI device, with offset
0.

If you have an accelerated driver, then it depends on the particular
driver.  Userspace-only drivers may need to know the physical address of
memory to initiate DMA.  Kernel-based drivers typically do DMA from the
kernel.

It's not really clear what you're asking though, or what you're trying
to accomplish.

- 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: <http://lists.x.org/archives/xorg/attachments/20100414/495a59ae/attachment.pgp>