On 04/16/2012 12:39 PM, Gerd Hoffmann wrote: > On 04/06/12 15:54, Hans de Goede wrote: > > Hi Gerd, > > > > While cherry picking some spice patches into my own qemu-kvm-1.0 branch, > > so that we can add them to Fedora-17 I noticed a significant slowdown > > after I was done cherry picking. Investigation has shown your > > "qxl: add optinal 64bit vram bar" patch to be the culprit. > > > > I noticed this using an old Fedora-14 32 bits vm with an xorg-x11-drv-qxl > > patched to use the async methods. > > > > If I scroll through the gnome applications menu with the mouse with > > plain qemu-kvm-1.0 all is fine, but once I add your: > > "qxl: add optinal 64bit vram bar" the updating of the display > > becomes noticably slower, the blue bar highlighting the selected > > menu entry becomes lagged compared to the mouse cursor. > > Avi? This looks like a memory aliasing issue. > > Old state: > vram bar, backed by memory > > New state: > vram bar, 64bit, backed by memory, might not be mapped. > vram bar, 32bit, alias for the first part of the 64bit bar. > > Full patch: > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=6f2b175a090f367c3aab2226c4741b439671307a > > Any hints? >
(qemu) info mtree ... pci ... 00000000fc022000-00000000fc022fff (prio 1): alias qxl.vram32 @qxl.vram 0000000000000000-0000000000000fff ... qxl.vram 0000000000000000-0000000000000fff (prio 0): qxl.vram Looks like both the BAR and it's backing region were initialized to 4k. The number 4096 does show up in the patch, probably it sneaked into the BAR somehow. -- error compiling committee.c: too many arguments to function _______________________________________________ Spice-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/spice-devel
