* error when pass through device to guest with qemu-xen-dir-remote @ 2012-08-03 2:59 Zhang, Yang Z 2012-08-03 10:29 ` Stefano Stabellini 0 siblings, 1 reply; 15+ messages in thread From: Zhang, Yang Z @ 2012-08-03 2:59 UTC (permalink / raw) To: xen-devel; +Cc: anthony.perard, Ian Campbell, Stefano Stabellini 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? 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. best regards yang ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: error when pass through device to guest with qemu-xen-dir-remote 2012-08-03 2:59 error when pass through device to guest with qemu-xen-dir-remote Zhang, Yang Z @ 2012-08-03 10:29 ` Stefano Stabellini 2012-08-03 10:36 ` Ian Campbell 0 siblings, 1 reply; 15+ messages in thread From: Stefano Stabellini @ 2012-08-03 10:29 UTC (permalink / raw) To: Zhang, Yang Z; +Cc: Anthony Perard, Stefano Stabellini, Ian Campbell, xen-devel 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! 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: error when pass through device to guest with qemu-xen-dir-remote 2012-08-03 10:29 ` Stefano Stabellini @ 2012-08-03 10:36 ` Ian Campbell 2012-08-09 6:49 ` Zhou, Chao 0 siblings, 1 reply; 15+ messages in thread From: Ian Campbell @ 2012-08-03 10:36 UTC (permalink / raw) To: Stefano Stabellini; +Cc: Zhang, Yang Z, Anthony Perard, xen-devel 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: error when pass through device to guest with qemu-xen-dir-remote 2012-08-03 10:36 ` Ian Campbell @ 2012-08-09 6:49 ` Zhou, Chao 2012-08-14 1:17 ` Zhang, Yang Z 2012-08-27 3:03 ` Zhou, Chao 0 siblings, 2 replies; 15+ messages in thread From: Zhou, Chao @ 2012-08-09 6:49 UTC (permalink / raw) To: Ian Campbell, Stefano Stabellini; +Cc: Zhang, Yang Z, Anthony Perard, xen-devel 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@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org] 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@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: error when pass through device to guest with qemu-xen-dir-remote 2012-08-09 6:49 ` Zhou, Chao @ 2012-08-14 1:17 ` Zhang, Yang Z 2012-08-22 5:56 ` Shan, Haitao 2012-08-27 3:03 ` Zhou, Chao 1 sibling, 1 reply; 15+ messages in thread From: Zhang, Yang Z @ 2012-08-14 1:17 UTC (permalink / raw) To: Zhou, Chao, Ian Campbell, Stefano Stabellini; +Cc: Anthony Perard, xen-devel Zhou, Chao wrote on 2012-08-09: > 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. Hi Anthony, We cannot see the device(via lspci) after guest boot up with upstream QEMU. Did you see the same problem? We follow the steps from wiki to build QEMU upstream and do the device assignment through old way(1. hide the device, 2 set the bdf in config file). > -----Original Message----- From: xen-devel-bounces@lists.xen.org > [mailto:xen-devel-bounces@lists.xen.org] 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@lists.xen.org > http://lists.xen.org/xen-devel Best regards, Yang ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: error when pass through device to guest with qemu-xen-dir-remote 2012-08-14 1:17 ` Zhang, Yang Z @ 2012-08-22 5:56 ` Shan, Haitao 2012-08-22 10:54 ` Anthony PERARD 0 siblings, 1 reply; 15+ messages in thread From: Shan, Haitao @ 2012-08-22 5:56 UTC (permalink / raw) To: Zhang, Yang Z, Zhou, Chao, Ian Campbell, Stefano Stabellini Cc: Anthony Perard, Dugger, Donald D, xen-devel Hi, Do we have any conclusion on this? A bug? We are trying to contribute codes to Xen. However, this bug has blocked us for some time. It would be great to see this fixed. Shan Haitao -----Original Message----- From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Zhang, Yang Z Sent: Tuesday, August 14, 2012 9:18 AM To: Zhou, Chao; Ian Campbell; Stefano Stabellini Cc: Anthony Perard; xen-devel Subject: Re: [Xen-devel] error when pass through device to guest with qemu-xen-dir-remote Zhou, Chao wrote on 2012-08-09: > 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. Hi Anthony, We cannot see the device(via lspci) after guest boot up with upstream QEMU. Did you see the same problem? We follow the steps from wiki to build QEMU upstream and do the device assignment through old way(1. hide the device, 2 set the bdf in config file). > -----Original Message----- From: xen-devel-bounces@lists.xen.org > [mailto:xen-devel-bounces@lists.xen.org] 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@lists.xen.org > http://lists.xen.org/xen-devel Best regards, Yang _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: error when pass through device to guest with qemu-xen-dir-remote 2012-08-22 5:56 ` Shan, Haitao @ 2012-08-22 10:54 ` Anthony PERARD 0 siblings, 0 replies; 15+ messages in thread From: Anthony PERARD @ 2012-08-22 10:54 UTC (permalink / raw) To: Shan, Haitao Cc: Ian Campbell, Stefano Stabellini, Dugger, Donald D, xen-devel, Zhou, Chao, Zhang, Yang Z On Wed, Aug 22, 2012 at 6:56 AM, Shan, Haitao <haitao.shan@intel.com> wrote: > Do we have any conclusion on this? A bug? > We are trying to contribute codes to Xen. However, this bug has blocked us for some time. It would be great to see this fixed. I just try to start a guest with a network card passthrough, and it seams to work fine (the card is present in `lspci`). Maybe having some debug could help to understand the issue. Try to run `xl -vvv create ....`. Regards, -- Anthony PERARD ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: error when pass through device to guest with qemu-xen-dir-remote 2012-08-09 6:49 ` Zhou, Chao 2012-08-14 1:17 ` Zhang, Yang Z @ 2012-08-27 3:03 ` Zhou, Chao 2012-09-11 7:49 ` Zhang, Yang Z 2012-09-18 0:46 ` Zhang, Yang Z 1 sibling, 2 replies; 15+ messages in thread From: Zhou, Chao @ 2012-08-27 3:03 UTC (permalink / raw) To: Ian Campbell, Stefano Stabellini Cc: Zhang, Yang Z, Anthony Perard, Shan, Haitao, xen-devel 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@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org] 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@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org] 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@lists.xen.org http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: error when pass through device to guest with qemu-xen-dir-remote 2012-08-27 3:03 ` Zhou, Chao @ 2012-09-11 7:49 ` Zhang, Yang Z 2012-09-18 0:46 ` Zhang, Yang Z 1 sibling, 0 replies; 15+ messages in thread From: Zhang, Yang Z @ 2012-09-11 7:49 UTC (permalink / raw) To: Zhou, Chao, Ian Campbell, Stefano Stabellini Cc: Anthony Perard, Shan, Haitao, xen-devel > -----Original Message----- From: xen-devel-bounces@lists.xen.org > [mailto:xen-devel-bounces@lists.xen.org] 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@lists.xen.org > [mailto:xen-devel-bounces@lists.xen.org] 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. Hi Anthony I found the issue is caused by PV driver. Since RHEL6 integrated PV driver by default, when booting rhel6 as guest, it will load the PV driver and write the xen platform device to notify qemu to unplug all NICs including the pass through device. This definitely is wrong. We only need to unplug the emulator device, and leave pass through device. Best regards, Yang ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: error when pass through device to guest with qemu-xen-dir-remote 2012-08-27 3:03 ` Zhou, Chao 2012-09-11 7:49 ` Zhang, Yang Z @ 2012-09-18 0:46 ` Zhang, Yang Z 2012-09-18 10:49 ` Anthony PERARD 1 sibling, 1 reply; 15+ messages in thread From: Zhang, Yang Z @ 2012-09-18 0:46 UTC (permalink / raw) To: Zhang, Yang Z, Zhou, Chao, Ian Campbell, Stefano Stabellini Cc: Anthony Perard, Shan, Haitao, xen-devel Zhang, Yang Z wrote on 2012-09-11: > wrote on August 09, 2012 2:49 PM To: Ian Campbell; Stefano Stabellini: >> 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@lists.xen.org >> [mailto:xen-devel-bounces@lists.xen.org] 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. > > Hi Anthony > > I found the issue is caused by PV driver. Since RHEL6 integrated PV driver by > default, when booting rhel6 as guest, it will load the PV driver and write the xen > platform device to notify qemu to unplug all NICs including the pass through > device. This definitely is wrong. We only need to unplug the emulator device, and > leave pass through device. Hi Anthony, Any comments for this? Best regards, Yang ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: error when pass through device to guest with qemu-xen-dir-remote 2012-09-18 0:46 ` Zhang, Yang Z @ 2012-09-18 10:49 ` Anthony PERARD 2012-09-19 0:06 ` Zhang, Yang Z 0 siblings, 1 reply; 15+ messages in thread From: Anthony PERARD @ 2012-09-18 10:49 UTC (permalink / raw) To: Zhang, Yang Z Cc: xen-devel, Stefano Stabellini, Shan, Haitao, Zhou, Chao, Ian Campbell On 09/18/2012 01:46 AM, Zhang, Yang Z wrote: > Zhang, Yang Z wrote on 2012-09-11: >> wrote on August 09, 2012 2:49 PM To: Ian Campbell; Stefano Stabellini: >>> 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@lists.xen.org >>> [mailto:xen-devel-bounces@lists.xen.org] 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. >> >> Hi Anthony >> >> I found the issue is caused by PV driver. Since RHEL6 integrated PV driver by >> default, when booting rhel6 as guest, it will load the PV driver and write the xen >> platform device to notify qemu to unplug all NICs including the pass through >> device. This definitely is wrong. We only need to unplug the emulator device, and >> leave pass through device. > > Hi Anthony, > > Any comments for this? Hi, So, we'll have to add a check in the unplug code of qemu to ignore passthrough devices. Here is a patches, I did not test it. diff --git a/hw/xen_platform.c b/hw/xen_platform.c index 0d6c2ff..2d3978e 100644 --- a/hw/xen_platform.c +++ b/hw/xen_platform.c @@ -85,8 +85,10 @@ static void log_writeb ... static void unplug_nic(PCIBus *b, PCIDevice *d, void *o) { + /* We have to ignore passthrough devices */ if (pci_get_word(d->config + PCI_CLASS_DEVICE) == - PCI_CLASS_NETWORK_ETHERNET) { + PCI_CLASS_NETWORK_ETHERNET + && strcmp(d->name, "xen-pci-passthrough") != 0) { qdev_free(&d->qdev); } } Thanks, -- Anthony PERARD ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: error when pass through device to guest with qemu-xen-dir-remote 2012-09-18 10:49 ` Anthony PERARD @ 2012-09-19 0:06 ` Zhang, Yang Z 2012-09-19 10:38 ` Anthony PERARD 0 siblings, 1 reply; 15+ messages in thread From: Zhang, Yang Z @ 2012-09-19 0:06 UTC (permalink / raw) To: Anthony PERARD Cc: xen-devel, Stefano Stabellini, Shan, Haitao, Zhou, Chao, Ian Campbell Anthony PERARD wrote on 2012-09-18: > > Hi, > > So, we'll have to add a check in the unplug code of qemu to ignore > passthrough devices. > > Here is a patches, I did not test it. > > diff --git a/hw/xen_platform.c b/hw/xen_platform.c > index 0d6c2ff..2d3978e 100644 > --- a/hw/xen_platform.c > +++ b/hw/xen_platform.c > @@ -85,8 +85,10 @@ static void log_writeb ... > > static void unplug_nic(PCIBus *b, PCIDevice *d, void *o) > { > + /* We have to ignore passthrough devices */ > if (pci_get_word(d->config + PCI_CLASS_DEVICE) == > - PCI_CLASS_NETWORK_ETHERNET) { > + PCI_CLASS_NETWORK_ETHERNET > + && strcmp(d->name, "xen-pci-passthrough") != 0) { > qdev_free(&d->qdev); > } > } In old qemu, we will free the invalid NIC through this function. And it will fail w/ your change. Shouldn't we follow the old logic? Best regards, Yang ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: error when pass through device to guest with qemu-xen-dir-remote 2012-09-19 0:06 ` Zhang, Yang Z @ 2012-09-19 10:38 ` Anthony PERARD 2012-09-19 23:30 ` Zhang, Yang Z 0 siblings, 1 reply; 15+ messages in thread From: Anthony PERARD @ 2012-09-19 10:38 UTC (permalink / raw) To: Zhang, Yang Z Cc: Ian Campbell, Stefano Stabellini, Shan, Haitao, Zhou, Chao, xen-devel On Wed, Sep 19, 2012 at 1:06 AM, Zhang, Yang Z <yang.z.zhang@intel.com> wrote: > Anthony PERARD wrote on 2012-09-18: >> >> Hi, >> >> So, we'll have to add a check in the unplug code of qemu to ignore >> passthrough devices. >> >> Here is a patches, I did not test it. >> >> diff --git a/hw/xen_platform.c b/hw/xen_platform.c >> index 0d6c2ff..2d3978e 100644 >> --- a/hw/xen_platform.c >> +++ b/hw/xen_platform.c >> @@ -85,8 +85,10 @@ static void log_writeb ... >> >> static void unplug_nic(PCIBus *b, PCIDevice *d, void *o) >> { >> + /* We have to ignore passthrough devices */ >> if (pci_get_word(d->config + PCI_CLASS_DEVICE) == >> - PCI_CLASS_NETWORK_ETHERNET) { >> + PCI_CLASS_NETWORK_ETHERNET >> + && strcmp(d->name, "xen-pci-passthrough") != 0) { >> qdev_free(&d->qdev); >> } >> } > > In old qemu, we will free the invalid NIC through this function. And it will fail w/ your change. Shouldn't we follow the old logic? I don't understand. Are you arguing this patch or the function it self? My change is fine and follow the old logic: do not do anything for a passthrough device. I now have tested the change, and QEMU work as espected, it will unplug the emulated NIC, and ignore any passthrough devices. So the guest can the passthroughed NIC. Thanks, -- Anthony PERARD ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: error when pass through device to guest with qemu-xen-dir-remote 2012-09-19 10:38 ` Anthony PERARD @ 2012-09-19 23:30 ` Zhang, Yang Z 2012-09-20 10:56 ` Anthony PERARD 0 siblings, 1 reply; 15+ messages in thread From: Zhang, Yang Z @ 2012-09-19 23:30 UTC (permalink / raw) To: Anthony PERARD Cc: Ian Campbell, Stefano Stabellini, Shan, Haitao, Zhou, Chao, xen-devel Anthony PERARD wrote on 2012-09-19: > On Wed, Sep 19, 2012 at 1:06 AM, Zhang, Yang Z <yang.z.zhang@intel.com> > wrote: >> Anthony PERARD wrote on 2012-09-18: >>> >>> Hi, >>> >>> So, we'll have to add a check in the unplug code of qemu to ignore >>> passthrough devices. >>> >>> Here is a patches, I did not test it. >>> >>> diff --git a/hw/xen_platform.c b/hw/xen_platform.c >>> index 0d6c2ff..2d3978e 100644 >>> --- a/hw/xen_platform.c >>> +++ b/hw/xen_platform.c >>> @@ -85,8 +85,10 @@ static void log_writeb ... >>> >>> static void unplug_nic(PCIBus *b, PCIDevice *d, void *o) >>> { >>> + /* We have to ignore passthrough devices */ >>> if (pci_get_word(d->config + PCI_CLASS_DEVICE) == >>> - PCI_CLASS_NETWORK_ETHERNET) { >>> + PCI_CLASS_NETWORK_ETHERNET >>> + && strcmp(d->name, "xen-pci-passthrough") != 0) { >>> qdev_free(&d->qdev); >>> } >>> } >> >> In old qemu, we will free the invalid NIC through this function. And it will fail w/ > your change. Shouldn't we follow the old logic? > > I don't understand. Are you arguing this patch or the function it self? > > My change is fine and follow the old logic: do not do anything for a > passthrough device. No. Old logic will unplug the passthrough device which mask as invalid. And this patch just ignores all passthrough device. I wonder whether this change will impact other part? If not, it should be ok. > I now have tested the change, and QEMU work as espected, it will > unplug the emulated NIC, and ignore any passthrough devices. So the > guest can the passthroughed NIC. > > Thanks, > > -- > Anthony PERARD Best regards, Yang ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: error when pass through device to guest with qemu-xen-dir-remote 2012-09-19 23:30 ` Zhang, Yang Z @ 2012-09-20 10:56 ` Anthony PERARD 0 siblings, 0 replies; 15+ messages in thread From: Anthony PERARD @ 2012-09-20 10:56 UTC (permalink / raw) To: Zhang, Yang Z Cc: Zhou, Chao, xen-devel, Shan, Haitao, Ian Campbell, Stefano Stabellini On Thu, Sep 20, 2012 at 12:30 AM, Zhang, Yang Z <yang.z.zhang@intel.com> wrote: >>> In old qemu, we will free the invalid NIC through this function. And it will fail w/ >> your change. Shouldn't we follow the old logic? >> >> I don't understand. Are you arguing this patch or the function it self? >> >> My change is fine and follow the old logic: do not do anything for a >> passthrough device. > No. Old logic will unplug the passthrough device which mask as invalid. And this patch just ignores all passthrough device. I probably miss something in qemu-traditional then. Anyway ... > I wonder whether this change will impact other part? If not, it should be ok. This should not have any impact on any other part of QEMU. Regards, -- Anthony PERARD ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2012-09-20 10:56 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-08-03 2:59 error when pass through device to guest with qemu-xen-dir-remote Zhang, Yang Z 2012-08-03 10:29 ` Stefano Stabellini 2012-08-03 10:36 ` Ian Campbell 2012-08-09 6:49 ` Zhou, Chao 2012-08-14 1:17 ` Zhang, Yang Z 2012-08-22 5:56 ` Shan, Haitao 2012-08-22 10:54 ` Anthony PERARD 2012-08-27 3:03 ` Zhou, Chao 2012-09-11 7:49 ` Zhang, Yang Z 2012-09-18 0:46 ` Zhang, Yang Z 2012-09-18 10:49 ` Anthony PERARD 2012-09-19 0:06 ` Zhang, Yang Z 2012-09-19 10:38 ` Anthony PERARD 2012-09-19 23:30 ` Zhang, Yang Z 2012-09-20 10:56 ` Anthony PERARD
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.