|
[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 |