[Spice-devel] Display configuration with 4 displays

[Gerd Hoffmann]

On Di, 2013-12-03 at 16:47 -0500, Jonathon Jongsma wrote:
> I've mentioned this issue to several people on IRC already, but Hans
> suggested that I bring it up on the email list to get some additional
> input. The issue I'm investigating is bug 1008312 [1], in which the
> guest display configuration misbehaves when you enable and maximize 4
> displays. What happens is that the vdagent reverts to a previous
> configuration because it is unable to reconfigure the displays as
> requested. Hans suggested that this is a known issue when the QXL
> driver has insufficient video memory. I attempted to verify that
> explanation by increasing my QXL video RAM from 64MB to 128MB[2], but
> it still didn't work. Looking at the XOrg logs, I noticed the
> following messages whenever the re-configuration failed:
> 
> [ 13499.334] (II) qxl(0): qxl_xf86crtc_resize: Placeholder resize 5120x820
> [ 13499.334] resizing primary to 5120x820
> [ 13499.334] resizing surface0 to 16793600
> [ 13499.334] resizing surface0 compiled out
> [ 13499.334] not resizing primary to virtual, leaving old virtual

This looks like X-Server log, so the guest doesn't use kms I guess?
Which host?  Which guest?

> I asked Alon about these lines and he suggested that these messages
> were expected -- this resizable surface stuff is ifdef'ed out because
> it's still WIP. That means that the QXL driver has a fixed surface
> size that can't be resized.  Which is fine -- I don't care too much if
> the surface is not resizable as long as it's large enough to not
> *require* resizing.  But notice that the driver attempts to resize the
> surface whenever the surface0 size exceeds about 16M (16793600). It
> seems that this value comes from VGA_RAM_SIZE, which is hard-coded as
> (16 * 1024 * 1024) in spiceqxl_driver.h, regardless of what I
> configure my QXL video memory to be.

Yep, the first 16M of the ram bar are used as vga framebuffer (in vga
mode, when the guest runs without qxl drivers) and the primary surface
lives there for historical reasons too.  The memory above 16M are used
by the guest to store qxl commands, image data etc.

There is also the vram bar which can be used to store additional
surfaces (offscreen pixmaps in X11 speak).

So, what are the options?

First, the guest can store the primary surface in the vram bar too.  The
qxl kms driver does this.  So with rhel7/fedora19+ guest you probably
don't see this problem.

Second, the guest can reserve more than 16M in the ram bar for the
primary surface.  There is nothing in qxl which enforces this split,
other than switching into vga mode might overwrite the first 16 MB.
Doing it at runtime might be tricky as you might have to move qxl data
structures out of the way to make room.  Doing it at initialization time
should be easy.  Either have some config option, or simply use 25% of
ram bar size by default (so when it is increased from 64MB to 128MB the
surface0 area is increased too from 16MB to 32MB).  I suspect the WIP
resize code Alon mentioned goes into that direction.  So this needs a
guest driver update.

Third, in newer qxl versions (rhel7/fedora host) the vga memory size is
configurable too instead of being fixed at 16MB.  In theory the guest
should apply this to the primary surface area too (assuming it reads the
size from the qxl rom bar instead of hard-coding it).

Unfortunaly none of these work for rhel6-on-rhel6, which I suspect is
what you are using.  Updating the qxl driver to implement the second
option looks like the best way to tackle it.

cheers,
  Gerd