[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Unable to get QXL vga working



Zhou Peng wrote
> 
> Hi Fantu,
> 
> Thanks for your response.
> 
> xl doesn't support qxl-related option at the moment.
> I will test upstream-qemu-xen these days, and if it works well
> with qxl device, I will be glad to add qxl support to xl.
> 
> Best,
> 
> On Thu, Apr 26, 2012 at 11:39 PM, Ian Campbell <Ian.Campbell@>
> wrote:
>> CCing Zhou Peng who originally added spice support to xl. Zhou, are you
>> interested in supporting this feature?
>>
>> On Thu, 2012-04-26 at 16:23 +0100, Fantu wrote:
>>> Dom0:
>>> Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
>>> 3.2.15-1, package blktap-dkms and all dependency packages for xen, spice
>>> and
>>> usb redirection.
>>> -------------------------
>>> /etc/modules
>>> ------------
>>> loop max_loop=64
>>> xenfs
>>> xen-evtchn
>>> blktap
>>> -------------------------
>>> hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset
>>> is
>>> 25249:a4e7fce6ee2b)
>>> vi Makefile # removed dist-kernel to not compile kernel
>>> -------------------------
>>> vi Config.mk # qemu upstream unstable and seabios upstream unstable for
>>> various spice and qxl bugfix
>>> ------------
>>> QEMU_UPSTREAM_URL ?= git://git.qemu.org/qemu.git
>>> SEABIOS_UPSTREAM_URL ?= git://git.seabios.org/seabios.git
>>> SEABIOS_UPSTREAM_TAG ?= rel-1.7.0
>>> -------------------------
>>> Added some patches:
>>> - autoconf: add variable for pass arbitrary options to qemu upstream v3
>>> - tools: Improve make deb
>>> -------------------------
>>> ./configure --enable-qemuu-spice --enable-qemuu-usbredir
>>> --enable-qemuu-debug
>>> -------------------------
>>> make deb
>>>
>>> Tested it on Windows XP domU with this xl configuration file:
>>> -------------------------------
>>> XP.cfg
>>> ---------
>>> name='XP'
>>> builder="hvm"
>>> memory=1024
>>> vcpus=2
>>> hap=1
>>> pae=1
>>> acpi=1
>>> apic=1
>>> nx=1
>>> vif=['bridge=xenbr0']
>>> #vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
>>> #disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw',',raw,hdb,ro,cdrom']
>>> disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw']
>>> boot='cd'
>>> xen_platform_pci=1
>>> viridian=1
>>> device_model_version="qemu-xen"
>>> #device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
>>> #vnc=1
>>> #vncunused=1
>>> #vnclisten="0.0.0.0"
>>> #keymap="it"
>>> spice=1
>>> spicehost="0.0.0.0"
>>> spiceport=6000
>>> spicedisable_ticketing=1
>>> on_poweroff="destroy"
>>> on_reboot="restart"
>>> on_crash="destroy"
>>> stdvga=1
>>> #device_model_args=["-vga qxl -global qxl-vga.vram_size_mb=16"]
>>> #videoram=128
>>> #device_model_args=["-vga qxl"]
>>> -------------------------------
>>> With stdvga option domU is working but graphic performance is poor with
>>> spice.
>>>
>>>
>>> With QXL vga option domU
>>> -------------------------------
>>> videoram=128
>>> device_model_args=["-vga qxl"]
>>> stdvga=0
>>> -------------------------------
>>> DomU not start, from qemu log:
>>> qemu-system-i386: -vga qxl: invalid option
>>>
>>> But the option is correct and if I add:
>>> device_model_override="/usr/lib/xen/bin/qemu-debug.sh"
>>>
>>> qemu-debug.sh launches the same qemu-system-i386 with same options and
>>> domU
>>> starts.
>>> DomU sees the QXL vga but only with 4 mb allocated and/or usabled
>>> instead of
>>> 64 mb of qemu default.
>>>
>>> We need domUs with good graphic performance, also with high resolution
>>> and
>>> also multimedia.
>>> We can not use gfx passthrough on our dom0s because of hardware
>>> limitation
>>> of dell server.
>>> QXL seems to be the only way to go.
>>>
>>> We are testing this setup several months without success on xen.
>>> Some initial xl and qemu ram/videoram bugs are now fixed but may be
>>> there
>>> are other in xen not found for now.
>>>
>>> We noticed one particular thing:
>>>
>>> without qxl:
>>> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>>> Â Loader: Â Â Â Â0000000000100000->000000000019dc88
>>> Â TOTAL: Â Â Â Â 0000000000000000->000000003f800000
>>> Â ENTRY ADDRESS: 0000000000100000
>>>
>>> with qxl:
>>> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>>> Â Loader: Â Â Â Â0000000000100000->000000000019dc88
>>> Â TOTAL: Â Â Â Â 0000000000000000->0000000038000000
>>> Â ENTRY ADDRESS: 0000000000100000
>>>
>>> The total memory with qxl should be equal or major than total memory
>>> without
>>> qxl.
>>> There is something wrong about videoram, i don't know if in xl or other
>>> part
>>> of xen.
>>>
>>> Please someone help me to solve this problem?
>>>
>>> --
>>> View this message in context:
>>> http://xen.1045712.n5.nabble.com/Unable-to-get-QXL-vga-working-tp5667919p5667919.html
>>> Sent from the Xen - Dev mailing list archive at Nabble.com.
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@.xen
>>> http://lists.xen.org/xen-devel
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@.xen
>> http://lists.xen.org/xen-devel
> 
> 
> 
> -- 
> Zhou Peng
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@.xen
> http://lists.xen.org/xen-devel
> 


Thanks for reply, about QXL some patches need to be backported from qemu
upstream unstable to qemu upstream xen, now I don't know exactly which of
them solve the domU boot problem with spice and qxl, with qemu and seabios
of xen (1.0.1) doesn't work while with qemu and seabios unstable it does.
There are also some videoram bug or problem on xen, probably bugfix/patch
are necessary also outside of libxl, I tried to look for the problem and
solve it myself but I don't have enough knowledge now.

--
View this message in context: 
http://xen.1045712.n5.nabble.com/Unable-to-get-QXL-vga-working-tp5667919p5669805.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.