[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] error when pass through device to guest with qemu-xen-dir-remote
Here's the output of 'xl -vvv create' libxl: debug: libxl_create.c:1143:do_domain_create: ao 0xfc43f0: create: how=(nil) callback=(nil) poller=0xfc4c50 libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=unknown libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hda, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:184:disk_try_backend: Disk vdev=hda, backend tap unsuitable because blktap not available libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk vdev=hda, using backend qdisk libxl: debug: libxl_create.c:677: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:561:libxl__ev_xswatch_deregister: watch w=0xfc4fb0: deregister unregistered xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x9a6e4 xc: detail: elf_parse_binary: memory: 0x100000 -> 0x19a6e4 xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->000000000019a6e4 TOTAL: 0000000000000000->000000007f800000 ENTRY ADDRESS: 0000000000100000 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000003fb 1GB PAGES: 0x0000000000000000 xc: detail: elf_load_binary: phdr 0 at 0x0x7fbcdfd49000 -> 0x0x7fbcdfdda55c libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=qdisk libxl: debug: libxl_dm.c:1142:libxl__spawn_local_dm: Spawning device-model /usr/local/qemu-test/bin/qemu-system-x86_64 with arguments: libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: /usr/local/qemu-test/bin/qemu-system-x86_64 libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -xen-domid libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: 2 libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -chardev libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-2,server,nowait libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -mon libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: chardev=libxl-cmd,mode=control libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -name libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: example.hvm libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -vnc libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: 127.0.0.1:0,to=99 libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -serial libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: pty libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -vga libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: cirrus libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -boot libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: order=cda libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -smp libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: 4,maxcpus=4 libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -net libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: none libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -M libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: xenfv libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -m libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: 2040 libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -drive libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: file=/root/czhou/ia32e_rhel6u2.img,if=ide,index=0,media=disk,format=raw libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch w=0xfc51e8 wpath=/local/domain/0/device-model/2/state token=3/0: register slotnum=3 libxl: debug: libxl_create.c:1156:do_domain_create: ao 0xfc43f0: inprogress: poller=0xfc4c50, flags=i libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0xfc51e8 wpath=/local/domain/0/device-model/2/state token=3/0: event epath=/local/domain/0/device-model/2/state libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0xfc51e8 wpath=/local/domain/0/device-model/2/state token=3/0: event epath=/local/domain/0/device-model/2/state libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch w=0xfc51e8 wpath=/local/domain/0/device-model/2/state token=3/0: deregister slotnum=3 libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0xfc51e8: deregister unregistered libxl: debug: libxl_qmp.c:646:libxl__qmp_initialize: connected to /var/run/xen/qmp-libxl-2 libxl: debug: libxl_qmp.c:298: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:298: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:298: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:298:qmp_handle_response: message type: return libxl: debug: libxl_qmp.c:646:libxl__qmp_initialize: connected to /var/run/xen/qmp-libxl-2 libxl: debug: libxl_qmp.c:298: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:298:qmp_handle_response: message type: return libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: '{ "execute": "device_add", "id": 2, "arguments": { "driver": "xen-pci-passthrough", "id": "pci-pt-09_11.0", "hostaddr": "0000:09:11.0" } } ' libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: '{ "execute": "query-pci", "id": 3 } ' libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return libxl: debug: libxl_pci.c:85:libxl__create_pci_backend: Creating pci backend libxl: debug: libxl_event.c:1667:libxl__ao_progress_report: ao 0xfc43f0: progress report: ignored libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0xfc43f0: complete, rc=0 libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0xfc43f0: destroy xc: debug: hypercall buffer: total allocations:979 total releases:979 xc: debug: hypercall buffer: current allocations:0 maximum allocations:2 xc: debug: hypercall buffer: cache current size:2 xc: debug: hypercall buffer: cache hits:975 misses:2 toobig:2 Parsing config from xlexample.hvm Daemon running with PID 13533 Thanks, Zhou Chao -----Original Message----- From: xen-devel-bounces@xxxxxxxxxxxxx [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of Zhou, Chao Sent: Thursday, August 09, 2012 2:49 PM To: Ian Campbell; Stefano Stabellini Cc: Zhang, Yang Z; Anthony Perard; xen-devel Subject: Re: [Xen-devel] error when pass through device to guest with qemu-xen-dir-remote I rebuild the upstream QEMU according to the wiki, but device static assignment doesn't work, no lspci output in guest. However hotplug & unplug works fine. -----Original Message----- From: xen-devel-bounces@xxxxxxxxxxxxx [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of Ian Campbell Sent: Friday, August 03, 2012 6:36 PM To: Stefano Stabellini Cc: Zhang, Yang Z; Anthony Perard; xen-devel Subject: Re: [Xen-devel] error when pass through device to guest with qemu-xen-dir-remote On Fri, 2012-08-03 at 11:29 +0100, Stefano Stabellini wrote: > On Fri, 3 Aug 2012, Zhang, Yang Z wrote: > > When create guest with device assigned, it shows the error and the device > > wasn't able to work inside guest: > > libxl: error: libxl_qmp.c:288:qmp_handle_error_response: received an > > error message from QMP server: Parameter 'driver' expects a driver > > name > > > > It only fails with qemu-xen-dir-remote(Is this tree more close to upstream > > qemu?). I don't see the error with the traditional Qemu. > > I also tried qemu-upstream, but it fails when I try to enable pci > > pass-through for xen. I think Anthony's patch to add pci pass-through > > support for Xen is accepted by qemu-upstream, am I right? > > Yes, it was accepted, but it is present only in upstream QEMU (from > git://git.qemu.org/qemu.git), not the tree we are currently using in > xen-unstable for development > (git://xenbits.xensource.com/qemu-upstream-unstable.git). > Make sure you are using the right tree! http://wiki.xen.org/wiki/QEMU_Upstream has some notes on how to use the upstream qemu tree instead of our stable branch of upstream. > > Anthony is currently on vacation and is going to be back in about a > week. > > > Another question: > > Now I am trying to add some features (relevant to pass through device) to > > Qemu, which tree should I use? Since traditional qemu is great different > > from qemu-upstream, it is too old to develop patch base on it. But besides > > the old one, I cannot find a working qemu. > > You should use upstream QEMU, I am going to rebase our tree on that > early on in the 4.3 release cycle. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |