[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


 


Rackspace

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