In POST:
http://post-office.corp.redhat.com/archives/rhvirt-patches/2013-March/msg00025.html

Markus, can you help us determine if there is anything in QMP, -help, and/or -device "?" output, which can be used to distinguish between RHEL 6.3 (non-working '-device qxl-vga', where we had to use '-vga qxl' instead) and RHEL 6.4?  Do we need to spawn a BZ against qemu-kvm to give us such a distinguishing factor?

The qemu-kvm backport that brought us the feature (bug 770842) we'd like to detect here stopped right before upstream commit ddd8fdc7 "spice: make number of surfaces runtime-configurable."  Backporting that one on top makes sense to me on its own, and it has the added benefit of exposing a new property libvirt could test to detect the feature.

Please check with Alon whether we need a separate BZ to track the backport of ddd8fdc7.

bug 921128 tracks the qemu change to export a witness; I will go ahead and redo the libvirt side assuming that witness will be backported to 6.4.z.

Back in POST:
http://post-office.corp.redhat.com/archives/rhvirt-patches/2013-March/msg00183.html

Yet more IRC conversation - it turns out that use of '-vga qxl' vs. '-device qxl-vga' appears to be completely orthogonal to whether ram_size can be exposed.  This bug was originally asking for ram_size, which my original patches (comment 4) were able to use.  The only remaining patch (comment 11) is solely about using -device, which is what lets the user choose something other than 0:0:2.0 for the display PCI address; apparently -device is STILL unusable for the RHEL 6.4 qemu, but no one in RHEL cares that we are hard-coded to 0:0:2.0.  That is, if multiple displays requires multiple PCI addresses, then you want the addresses to be configurable; but if multiple displays can all be routed through a single address, then hard-coding that address is fine.  The point of configurable ram_size is to deal with the fact that we are able to route multiple displays through one address.

Put another way, it's probably my own fault for volunteering to do a backport of qxl-related patches, without being the original author of any of the upstream work.  Only now, after lots of IRC discussions, am I finally starting to realize that there are two ways to get multi-head support, one via multiple PCI addresses (requiring '-device qxl-vga'), and one requiring additional ram through a single address (requiring ram_size).  I had blindly backported ALL qxl patches, without distinguishing which of the two approaches they were good for, and then got confused when the -device qxl-vga approach was hard-coded to a version check.

verify with build:
libvirt-0.10.2-18.el6_4.1.x86_64
qemu-img-rhev-0.12.1.2-2.355.el6.x86_64

step:
1:create a guest with spice, edit xml
.....
  <graphics type='spice' autoport='yes' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>
.....
 <video>
      <model type='qxl' ram='65536' vram='65536' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
......
2: start guest
#virsh start win2012
Domain win2012 started

check qemu cmd:
#ps -ef | grep kvm
.....
-vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864 -device qxl,id=video1,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x7 
.....
3: try multiple qxl device:
edit guest xml add three qxl device then start the guest, check qemu cmd,
.....
-vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864 -device qxl,id=video1,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x7 -device qxl,id=video2,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x8
.....
verification passed.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0664.html