Fabio Fantoni
2013-Sep-24 11:13 UTC
Qxl problem with xen domU, is xen spice and/or qemu bugs?
I''ve been trying to have all spice features working on xen domUs since
the end of 2011.
Basic functions were already working. Adding qemu parameters manually
for vdagent and usbredirection was and is also working (I made the
patches to support them directly on xl).
Qxl was never working: one bug on xen and one on qemu about qxl are
fixed, the other xen bug found months ago on the link below seems to be
solved by latest Jan Beulich patches.
http://lists.xen.org/archives/html/xen-devel/2013-05/msg02050.html
Now I can''t find other xen errors on the logs; qemu doesn''t
crash
anymore and on my latest tests with Fedora19 domU the only strange
things are high load on the X process and some lines on X.org logs. All
logs about Fedora domU with qxl test are below or in the attachments.
Dom0 details:
Wheezy 64 bit with kernel from package linux-image-3.2.0-4-amd64 version
3.2.46-1+deb7u1 and all dependency packages for xen, spice and usb
redirection.
Seabios 1.7.3-1, spice 0.12.4-0nocelt1 and usbredir 0.6-2 compiled from
debian unstable sources.
The Qemu version used is 1.6 compiled from source and xen from git
(commit 14fcce2fa883405bab26b60821a6cc5f2c770833), and the latest qxl
patch for libxl:
http://lists.xen.org/archives/html/xen-devel/2013-09/msg02386.html
Someone can help me to find the problem that makes qxl unusable please?
If you need more tests/details tell me and I''ll post them.
Thanks for any reply.
xl -vvv create /etc/xen/FEDORA19.cfg
------------------------------------------------------------------------
Parsing config from /etc/xen/FEDORA19.cfg
libxl: debug: libxl_create.c:1252:do_domain_create: ao 0x193a970:
create: how=(nil) callback=(nil) poller=0x193b630
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=hda spec.backend=unknown
libxl: debug: libxl_device.c:197:disk_try_backend: Disk vdev=hda,
backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:296:libxl__device_disk_set_backend: Disk
vdev=hda, using backend qdisk
libxl: debug: libxl_create.c:697:initiate_domain_create: running bootloader
libxl: debug: libxl_bootloader.c:321:libxl__bootloader_run: not a PV
domain, skipping bootloader
libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch
w=0x193b998: deregister unregistered
libxl: debug: libxl_numa.c:475:libxl__get_numa_candidate: New best NUMA
placement candidate found: nr_nodes=1, nr_cpus=8, nr_vcpus=10,
free_memkb=9050
libxl: detail: libxl_dom.c:195:numa_place_domain: NUMA placement
candidate with 1 nodes, 8 cpus and 9050 KB free selected
xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x9efa8
xc: detail: elf_parse_binary: memory: 0x100000 -> 0x19efa8
xc: detail: VIRTUAL MEMORY ARRANGEMENT:
Loader: 0000000000100000->000000000019efa8
Modules: 0000000000000000->0000000000000000
TOTAL: 0000000000000000->0000000078000000
ENTRY ADDRESS: 0000000000100000
xc: detail: PHYSICAL MEMORY ALLOCATION:
4KB PAGES: 0x0000000000000200
2MB PAGES: 0x00000000000003bf
1GB PAGES: 0x0000000000000000
xc: detail: elf_load_binary: phdr 0 at 0x7f04a5b8f000 -> 0x7f04a5c24e2d
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=hda spec.backend=qdisk
libxl: debug: libxl_dm.c:1280:libxl__spawn_local_dm: Spawning
device-model /usr/lib/xen/bin/qemu-system-i386 with arguments:
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm:
/usr/lib/xen/bin/qemu-system-i386
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: -xen-domid
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: 6
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: -chardev
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm:
socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-6,server,nowait
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: -mon
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm:
chardev=libxl-cmd,mode=control
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: -name
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: FEDORA19
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: -k
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: it
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: -global
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: isa-fdc.driveAlibxl: debug:
libxl_dm.c:1282:libxl__spawn_local_dm: -spice
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm:
port=6002,tls-port=0,addr=0.0.0.0,disable-ticketing,agent-mouse=on,disable-copy-paste
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: -device
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: virtio-serial
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: -chardev
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm:
spicevmc,id=vdagent,name=vdagent
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: -device
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm:
virtserialport,chardev=vdagent,name=com.redhat.spice.0
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: -device
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm:
qxl-vga,vram_size_mb=64,ram_size_mb=64
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: -boot
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: order=c
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: -smp
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: 2,maxcpus=2
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: -device
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm:
rtl8139,id=nic0,netdev=net0,mac=00:16:3e:41:a1:e6
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: -netdev
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm:
type=tap,id=net0,ifname=vif6.0-emu,script=no,downscript=no
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: -M
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: xenfv
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: -m
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: 1920
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: -drive
libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm:
file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback
libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch
w=0x193bbd0 wpath=/local/domain/0/device-model/6/state token=3/0:
register slotnum=3
libxl: debug: libxl_create.c:1265:do_domain_create: ao 0x193a970:
inprogress: poller=0x193b630, flags=i
libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x193bbd0
wpath=/local/domain/0/device-model/6/state token=3/0: event
epath=/local/domain/0/device-model/6/state
libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x193bbd0
wpath=/local/domain/0/device-model/6/state token=3/0: event
epath=/local/domain/0/device-model/6/state
libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch
w=0x193bbd0 wpath=/local/domain/0/device-model/6/state token=3/0:
deregister slotnum=3
libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch
w=0x193bbd0: deregister unregistered
libxl: debug: libxl_qmp.c:707:libxl__qmp_initialize: connected to
/var/run/xen/qmp-libxl-6
libxl: debug: libxl_qmp.c:299:qmp_handle_response: message type: qmp
libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: ''{
"execute": "qmp_capabilities",
"id": 1
}
''
libxl: debug: libxl_qmp.c:299:qmp_handle_response: message type: return
libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: ''{
"execute": "query-chardev",
"id": 2
}
''
libxl: debug: libxl_qmp.c:299:qmp_handle_response: message type: return
libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: ''{
"execute": "query-vnc",
"id": 3
}
''
libxl: debug: libxl_qmp.c:299:qmp_handle_response: message type: return
libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch
w=0x193f648 wpath=/local/domain/0/backend/vif/6/0/state token=3/1:
register slotnum=3
libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x193f648
wpath=/local/domain/0/backend/vif/6/0/state token=3/1: event
epath=/local/domain/0/backend/vif/6/0/state
libxl: debug: libxl_event.c:647:devstate_watch_callback: backend
/local/domain/0/backend/vif/6/0/state wanted state 2 still waiting state 1
libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x193f648
wpath=/local/domain/0/backend/vif/6/0/state token=3/1: event
epath=/local/domain/0/backend/vif/6/0/state
libxl: debug: libxl_event.c:643:devstate_watch_callback: backend
/local/domain/0/backend/vif/6/0/state wanted state 2 ok
libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch
w=0x193f648 wpath=/local/domain/0/backend/vif/6/0/state token=3/1:
deregister slotnum=3
libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch
w=0x193f648: deregister unregistered
libxl: debug: libxl_device.c:959:device_hotplug: calling hotplug script:
/etc/xen/scripts/vif-bridge online
libxl: debug: libxl_device.c:959:device_hotplug: calling hotplug script:
/etc/xen/scripts/vif-bridge add
libxl: debug: libxl_event.c:1737:libxl__ao_progress_report: ao
0x193a970: progress report: ignored
libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao 0x193a970:
complete, rc=0
libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x193a970: destroy
Daemon running with PID 5581
xc: debug: hypercall buffer: total allocations:752 total releases:752
xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
xc: debug: hypercall buffer: cache current size:4
xc: debug: hypercall buffer: cache hits:744 misses:4 toobig:4
------------------------------------------------------------------------
xl dmesg logs of this domU
------------------------------------------------------------------------
(d6) HVM Loader
(d6) Detected Xen v4.4-unstable
(d6) Xenbus rings @0xfeffc000, event channel 4
(d6) System requested SeaBIOS
(d6) CPU speed is 2661 MHz
(d6) Relocating guest memory for lowmem MMIO space disabled
(XEN) irq.c:270: Dom6 PCI link 0 changed 0 -> 5
(d6) PCI-ISA link 0 routed to IRQ5
(XEN) irq.c:270: Dom6 PCI link 1 changed 0 -> 10
(d6) PCI-ISA link 1 routed to IRQ10
(XEN) irq.c:270: Dom6 PCI link 2 changed 0 -> 11
(d6) PCI-ISA link 2 routed to IRQ11
(XEN) irq.c:270: Dom6 PCI link 3 changed 0 -> 5
(d6) PCI-ISA link 3 routed to IRQ5
(d6) pci dev 01:3 INTA->IRQ10
(d6) pci dev 02:0 INTA->IRQ11
(d6) pci dev 03:0 INTA->IRQ5
(d6) pci dev 04:0 INTA->IRQ5
(d6) pci dev 05:0 INTA->IRQ10
(d6) No RAM in high memory; setting high_mem resource base to 100000000
(d6) pci dev 04:0 bar 10 size 004000000: 0f0000000
(d6) pci dev 04:0 bar 14 size 004000000: 0f4000000
(d6) pci dev 02:0 bar 14 size 001000000: 0f8000008
(d6) pci dev 05:0 bar 30 size 000040000: 0f9000000
(d6) pci dev 04:0 bar 30 size 000010000: 0f9040000
(d6) pci dev 04:0 bar 18 size 000002000: 0f9050000
(d6) pci dev 03:0 bar 14 size 000001000: 0f9052000
(d6) pci dev 02:0 bar 10 size 000000100: 00000c001
(d6) pci dev 05:0 bar 10 size 000000100: 00000c101
(d6) pci dev 05:0 bar 14 size 000000100: 0f9053000
(d6) pci dev 03:0 bar 10 size 000000020: 00000c201
(d6) pci dev 04:0 bar 1c size 000000020: 00000c221
(d6) pci dev 01:1 bar 20 size 000000010: 00000c241
(d6) Multiprocessor initialisation:
(d6) - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(d6) - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(d6) Testing HVM environment:
(d6) - REP INSB across page boundaries ... passed
(d6) - GS base MSRs and SWAPGS ... passed
(d6) Passed 2 of 2 tests
(d6) Writing SMBIOS tables ...
(d6) Loading SeaBIOS ...
(d6) Creating MP tables ...
(d6) Loading ACPI ...
(d6) vm86 TSS at fc00a080
(d6) BIOS map:
(d6) 10000-100d3: Scratch space
(d6) e0000-fffff: Main BIOS
(d6) E820 table:
(d6) [00]: 00000000:00000000 - 00000000:000a0000: RAM
(d6) HOLE: 00000000:000a0000 - 00000000:000e0000
(d6) [01]: 00000000:000e0000 - 00000000:00100000: RESERVED
(d6) [02]: 00000000:00100000 - 00000000:78000000: RAM
(d6) HOLE: 00000000:78000000 - 00000000:fc000000
(d6) [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
(d6) Invoking SeaBIOS ...
(d6) SeaBIOS (version debian/1.7.3-1-1-ga76c6f1-dirty-20130813_122010-vfarm)
(d6)
(d6) Found Xen hypervisor signature at 40000000
(d6) xen: copy e820...
(d6) Relocating init from 0x000e2001 to 0x77fe0600 (size 63795)
(d6) CPU Mhz=2662
(d6) Found 8 PCI devices (max PCI bus is 00)
(d6) Allocated Xen hypercall page at 77fff000
(d6) Detected Xen v4.4-unstable
(d6) xen: copy BIOS tables...
(d6) Copying SMBIOS entry point from 0x00010010 to 0x000f1920
(d6) Copying MPTABLE from 0xfc001170/fc001180 to 0x000f1820
(d6) Copying PIR from 0x00010030 to 0x000f17a0
(d6) Copying ACPI RSDP from 0x000100b0 to 0x000f1770
(d6) Using pmtimer, ioport 0xb008, freq 3579 kHz
(d6) Scan for VGA option rom
(d6) WARNING! Found unaligned PCI rom (vd=1b36:0100)
(d6) Running option rom at c000:0003
(XEN) stdvga.c:147:d6 entering stdvga and caching modes
(d6) Turning on vga text mode console
(d6) SeaBIOS (version debian/1.7.3-1-1-ga76c6f1-dirty-20130813_122010-vfarm)
(d6) Machine UUID 332971bb-8265-4ef7-a991-5a53da4ebef2
(d6) Found 1 lpt ports
(d6) Found 1 serial ports
(d6) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
(d6) ATA controller 2 at 170/374/0 (irq 15 dev 9)
(d6) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (10000 MiBytes)
(d6) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
(d6) DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD]
(d6) Searching bootorder for: /pci@i0cf8/*@1,1/drive@1/disk@0
(d6) PS2 keyboard initialized
(d6) All threads complete.
(d6) Scan for option roms
(d6) Running option rom at ca00:0003
(d6) pmm call arg1=1
(d6) pmm call arg1=0
(d6) pmm call arg1=1
(d6) pmm call arg1=0
(d6) Searching bootorder for: /pci@i0cf8/*@5
(d6)
(d6) Press F12 for boot menu.
(d6)
(d6) Searching bootorder for: HALT
(d6) drive 0x000f1720: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
s=20480000
(d6) Space available for UMB: cb000-ee800, f0000-f16c0
(d6) Returned 61440 bytes of ZoneHigh
(d6) e820 map has 6 items:
(d6) 0: 0000000000000000 - 000000000009fc00 = 1 RAM
(d6) 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
(d6) 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
(d6) 3: 0000000000100000 - 0000000077fff000 = 1 RAM
(d6) 4: 0000000077fff000 - 0000000078000000 = 2 RESERVED
(d6) 5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
(d6) enter handle_19:
(d6) NULL
(d6) Booting from Hard Disk...
(d6) Booting from 0000:7c00
(XEN) irq.c:375: Dom6 callback via changed to Direct Vector 0xf3
(XEN) irq.c:270: Dom6 PCI link 0 changed 5 -> 0
(XEN) irq.c:270: Dom6 PCI link 1 changed 10 -> 0
(XEN) irq.c:270: Dom6 PCI link 2 changed 11 -> 0
(XEN) irq.c:270: Dom6 PCI link 3 changed 5 -> 0
------------------------------------------------------------------------
/var/log/xen/qemu-dm-FEDORA19.log
------------------------------------------------------------------------
xc: error: linux_gnttab_set_max_grants: ioctl SET_MAX_GRANTS failed (22
= Invalid argument): Internal error
xen be: qdisk-768: xc_gnttab_set_max_grants failed: Invalid argument
main_channel_link: add main channel client
main_channel_handle_parsed: net test: latency 65.272000 ms, bitrate
569046957 bps (542.685468 Mbps)
inputs_connect: inputs channel client create
red_dispatcher_set_cursor_peer:
xen be: vkbd-0: initialise() failed
xen be: vkbd-0: initialise() failed
xen be: vkbd-0: initialise() failed
------------------------------------------------------------------------
Gerd Hoffmann
2013-Sep-24 11:50 UTC
Re: Qxl problem with xen domU, is xen spice and/or qemu bugs?
Hi,> Someone can help me to find the problem that makes qxl unusable please?#1 git cherry-pick c58c7b959b93b864a27fd6b3646ee1465ab8832b #2 When using f19 try without X11 first. You should have a working framebuffer console on qxldrmfb before trying to get X11 going. #3 qxl has a bunch of tracepoints. Enable them, then compare xen results with kvm/tcg results to see where things start going wrong. #4 qxl needs a permanent mapping of the two pci memory bars as the (host virtual) memory location of these bars is passed to the spice-server library. That might need some special care on xen due to the mapcache. Disclamer: It''s been a few years I looked closer at this, so things in the xen world might have changed meanwhile ... HTH, Gerd
Fabio Fantoni
2013-Sep-26 10:28 UTC
Re: Qxl problem with xen domU, is xen spice and/or qemu bugs?
[This email is either empty or too large to be displayed at this time]
Fabio Fantoni
2013-Sep-26 13:04 UTC
Re: Qxl problem with xen domU, is xen spice and/or qemu bugs?
Il 26/09/2013 12:28, Fabio Fantoni ha scritto:> Il 24/09/2013 13:50, Gerd Hoffmann ha scritto: >> Hi, >> >>> Someone can help me to find the problem that makes qxl unusable please? >> #1 git cherry-pick c58c7b959b93b864a27fd6b3646ee1465ab8832b > > Thanks for reply, did this on my new test build. > >> >> #2 When using f19 try without X11 first. You should have a working >> framebuffer console on qxldrmfb before trying to get X11 going. > > I tried on Fedora19 minimal installation and with qxl the text console > is working and lsmod show also qxl. > Is this your intended or is there something else I must test before X11? > >> >> #3 qxl has a bunch of tracepoints. Enable them, then compare xen >> results with kvm/tcg results to see where things start going wrong. > > I enabled qxl debug with these qemu paramters: > -global qxl-vga.debug=1 -global qxl-vga.guestdebug=20 > > With Fedora19 I have some difficult to found exact problem and compare > with kvm. > I tried to test Fedora19 on debian sid kvm host same qemu version > (1.6) on both sides but with qxl fails to start the DE, also in > fallback mode. Probably there are also regression on qemu and/or spice > about qxl. > The qemu log returns nothing relevant with only few lines on xen test > with also qxl debug enabled. > > I tried also W7 domU on xen with spice-guest-tools-0.65.exe and qxl: > domU starts, loads correctly the DE, vdagent and mouse are both > working, but screen refreshing is very lagging (also only open of > start menu). > The qemu log become of 22 mb in only few minutes, mainly qxl debug. > Can you check the W7 qemu log on attachment to see if there are > strange things to solve also on spice and/or qemu?Previous mail was reject by mailing lists because attachment was too big, I upload it here: http://www.filedropper.com/qemu-dm-w7> Thanks for any reply. > >> >> #4 qxl needs a permanent mapping of the two pci memory bars as the >> (host virtual) memory location of these bars is passed to the >> spice-server library. That might need some special care on xen >> due to the mapcache. Disclamer: It''s been a few years I looked >> closer at this, so things in the xen world might have changed >> meanwhile ... >> >> HTH, >> Gerd >> >> >
Gerd Hoffmann
2013-Sep-27 08:51 UTC
Re: [Qemu-devel] Qxl problem with xen domU, is xen spice and/or qemu bugs?
Hi,> >> #2 When using f19 try without X11 first. You should have a working > >> framebuffer console on qxldrmfb before trying to get X11 going. > > > > I tried on Fedora19 minimal installation and with qxl the text console > > is working and lsmod show also qxl.Good, so the kernel driver is running fine.> > Is this your intended?Yes.> >> #3 qxl has a bunch of tracepoints. Enable them, then compare xen > >> results with kvm/tcg results to see where things start going wrong. > > > > I enabled qxl debug with these qemu paramters: > > -global qxl-vga.debug=1 -global qxl-vga.guestdebug=20debug=1 doesn''t do much, most is in tracepoints these days. I''m using the stderr tracer most of the time (enable it using configure). Then you can turn on qxl_* either in monitor (trace-events command) or via -trace events=<file-with-event-names>.> > I tried to test Fedora19 on debian sid kvm host same qemu version > > (1.6) on both sides but with qxl fails to start the DE, also in > > fallback mode. Probably there are also regression on qemu and/or spice > > about qxl.I''m not aware of any regressions. I''d suggest to try latest spice-server release. HTH, Gerd
Fabio Fantoni
2013-Sep-27 13:53 UTC
Re: Qxl problem with xen domU, is xen spice and/or qemu bugs?
Il 27/09/2013 10:51, Gerd Hoffmann ha scritto:> Hi, > >>>> #2 When using f19 try without X11 first. You should have a working >>>> framebuffer console on qxldrmfb before trying to get X11 going. >>> I tried on Fedora19 minimal installation and with qxl the text console >>> is working and lsmod show also qxl. > Good, so the kernel driver is running fine. > >>> Is this your intended? > Yes. > >>>> #3 qxl has a bunch of tracepoints. Enable them, then compare xen >>>> results with kvm/tcg results to see where things start going wrong. >>> I enabled qxl debug with these qemu paramters: >>> -global qxl-vga.debug=1 -global qxl-vga.guestdebug=20 > debug=1 doesn''t do much, most is in tracepoints these days. I''m using > the stderr tracer most of the time (enable it using configure). Then > you can turn on qxl_* either in monitor (trace-events command) or via > -trace events=<file-with-event-names>.Thanks for reply, I used trace of qxl_* instead of -global debug options (is it right or must I maintain also global qxl debug option?). On attachment the new qemu log of windows 7 test with qxl vga. The test was made as for below:> I tried also W7 domU on xen with spice-guest-tools-0.65.exe and qxl: > domU starts, loads correctly the DE, vdagent and mouse are both > working, but screen refreshing is very lagging (also only open of > start menu).Can you check the log to see if there are strange things to fix also on spice and/or qemu? Thanks for any reply.>>> I tried to test Fedora19 on debian sid kvm host same qemu version >>> (1.6) on both sides but with qxl fails to start the DE, also in >>> fallback mode. Probably there are also regression on qemu and/or spice >>> about qxl. > I''m not aware of any regressions. > I''d suggest to try latest spice-server release.I double checked and is already to latest version: http://packages.debian.org/sid/libspice-server1> > HTH, > Gerd > > >
Fabio Fantoni
2013-Oct-01 12:52 UTC
Re: [Qemu-devel] Qxl problem with xen domU, is xen spice and/or qemu bugs?
Il 27/09/2013 15:53, Fabio Fantoni ha scritto:> Il 27/09/2013 10:51, Gerd Hoffmann ha scritto: >> Hi, >> >>>>> #2 When using f19 try without X11 first. You should have a working >>>>> framebuffer console on qxldrmfb before trying to get X11 going. >>>> I tried on Fedora19 minimal installation and with qxl the text console >>>> is working and lsmod show also qxl. >> Good, so the kernel driver is running fine. >> >>>> Is this your intended? >> Yes. >> >>>>> #3 qxl has a bunch of tracepoints. Enable them, then compare xen >>>>> results with kvm/tcg results to see where things start going >>>>> wrong. >>>> I enabled qxl debug with these qemu paramters: >>>> -global qxl-vga.debug=1 -global qxl-vga.guestdebug=20 >> debug=1 doesn''t do much, most is in tracepoints these days. I''m using >> the stderr tracer most of the time (enable it using configure). Then >> you can turn on qxl_* either in monitor (trace-events command) or via >> -trace events=<file-with-event-names>. > > Thanks for reply, I used trace of qxl_* instead of -global debug > options (is it right or must I maintain also global qxl debug option?). > On attachment the new qemu log of windows 7 test with qxl vga. > The test was made as for below: >> I tried also W7 domU on xen with spice-guest-tools-0.65.exe and qxl: >> domU starts, loads correctly the DE, vdagent and mouse are both >> working, but screen refreshing is very lagging (also only open of >> start menu). > > Can you check the log to see if there are strange things to fix also > on spice and/or qemu? > Thanks for any reply. > >>>> I tried to test Fedora19 on debian sid kvm host same qemu version >>>> (1.6) on both sides but with qxl fails to start the DE, also in >>>> fallback mode. Probably there are also regression on qemu and/or spice >>>> about qxl. >> I''m not aware of any regressions. >> I''d suggest to try latest spice-server release. > > I double checked and is already to latest version: > http://packages.debian.org/sid/libspice-server1 >After I updated Fedora19 vm on kvm, it works with qxl. I compared xen and kvm logs and the only relevant difference that I found is this line on /var/log/messages of xen domU:> ioremap error for 0xfc001000-0xfc002000, requested 0x10, got 0x0I attached all messages and Xorg logs for both xen and kvm (Fedora19) tests with qxl. And about xen hypervisor logs (with xl dmesg) the only difference between stdvga and qxl (same domU) is that qxl log has 3 "pci dev bar" more. Full logs on attachments. Thanks for any reply.>> >> HTH, >> Gerd >> >> >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Fabio Fantoni
2013-Dec-04 16:10 UTC
Re: [Qemu-devel] Qxl problem with xen domU, is xen spice and/or qemu bugs?
Il 01/10/2013 14:52, Fabio Fantoni ha scritto:> Il 27/09/2013 15:53, Fabio Fantoni ha scritto: >> Il 27/09/2013 10:51, Gerd Hoffmann ha scritto: >>> Hi, >>> >>>>>> #2 When using f19 try without X11 first. You should have a working >>>>>> framebuffer console on qxldrmfb before trying to get X11 going. >>>>> I tried on Fedora19 minimal installation and with qxl the text >>>>> console >>>>> is working and lsmod show also qxl. >>> Good, so the kernel driver is running fine. >>> >>>>> Is this your intended? >>> Yes. >>> >>>>>> #3 qxl has a bunch of tracepoints. Enable them, then compare xen >>>>>> results with kvm/tcg results to see where things start going >>>>>> wrong. >>>>> I enabled qxl debug with these qemu paramters: >>>>> -global qxl-vga.debug=1 -global qxl-vga.guestdebug=20 >>> debug=1 doesn''t do much, most is in tracepoints these days. I''m using >>> the stderr tracer most of the time (enable it using configure). Then >>> you can turn on qxl_* either in monitor (trace-events command) or via >>> -trace events=<file-with-event-names>. >> >> Thanks for reply, I used trace of qxl_* instead of -global debug >> options (is it right or must I maintain also global qxl debug option?). >> On attachment the new qemu log of windows 7 test with qxl vga. >> The test was made as for below: >>> I tried also W7 domU on xen with spice-guest-tools-0.65.exe and qxl: >>> domU starts, loads correctly the DE, vdagent and mouse are both >>> working, but screen refreshing is very lagging (also only open of >>> start menu). >> >> Can you check the log to see if there are strange things to fix also >> on spice and/or qemu? >> Thanks for any reply. >> >>>>> I tried to test Fedora19 on debian sid kvm host same qemu version >>>>> (1.6) on both sides but with qxl fails to start the DE, also in >>>>> fallback mode. Probably there are also regression on qemu and/or >>>>> spice >>>>> about qxl. >>> I''m not aware of any regressions. >>> I''d suggest to try latest spice-server release. >> >> I double checked and is already to latest version: >> http://packages.debian.org/sid/libspice-server1 >> > > After I updated Fedora19 vm on kvm, it works with qxl. > > I compared xen and kvm logs and the only relevant difference that I > found is this line on /var/log/messages of xen domU: >> ioremap error for 0xfc001000-0xfc002000, requested 0x10, got 0x0 > I attached all messages and Xorg logs for both xen and kvm (Fedora19) > tests with qxl. > > And about xen hypervisor logs (with xl dmesg) the only difference > between stdvga and qxl (same domU) is that qxl log has 3 "pci dev bar" > more. Full logs on attachments. > > Thanks for any reply. > >>> >>> HTH, >>> Gerd >>> >>> >>> >> >I made other tests with qxl using xen_platform_pci=0 (now that it is functioning with qemu upstream too). On a W7 domU the main problem with performances with qxl drivers seems to be solved but unfortunately I didn''t find a way to have both qxl and xen gplpv working. On a Saucy domU (ubuntu 13.10) with this kernel patch applied (see below): http://lists.xen.org/archives/html/xen-devel/2013-12/msg00583.html the black screen and X process to 100% persists. Attached the xorg log with a backtrace in it. Anyone on this please? Thanks for any reply.