Hi, Here is a little patch that attempt to fix the issue regarding xen_platform_pci=0 not been handled. There is one patch left from the previous version. The patch that was adding qemu_machine_override have been removed as it is unnecessary. If someone wants to change the -machine, it can always add it to device_model_args_hvm, as QEMU appear to use the last one. Regards, Anthony PERARD (1): libxl: Handle xen_platform_pci=0 case with qemu-xen. tools/libxl/libxl_dm.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) -- Anthony PERARD
Anthony PERARD
2013-Nov-27 18:21 UTC
[PATCH v2] libxl: Handle xen_platform_pci=0 case with qemu-xen.
This should result in QEMU *not* adding the xen-platform device.
Since QEMU 1.6, this can be achieved by using a different qemu machine.
The one used by libxl is "xenfv", but using QEMU >=1.6 with
"-machine
pc,accel=xen" works as well with only one difference compared to
"xenfv", there is no xen-platform device.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
tools/libxl/libxl_dm.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index be39a62..ea773b3 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -608,7 +608,8 @@ static char ** libxl__build_device_model_args_new(libxl__gc
*gc,
}
for (i = 0; b_info->extra && b_info->extra[i] != NULL; i++)
flexarray_append(dm_args, b_info->extra[i]);
- flexarray_append(dm_args, "-M");
+
+ flexarray_append(dm_args, "-machine");
switch (b_info->type) {
case LIBXL_DOMAIN_TYPE_PV:
flexarray_append(dm_args, "xenpv");
@@ -616,7 +617,14 @@ static char ** libxl__build_device_model_args_new(libxl__gc
*gc,
flexarray_append(dm_args, b_info->extra_pv[i]);
break;
case LIBXL_DOMAIN_TYPE_HVM:
- flexarray_append(dm_args, "xenfv");
+ if (!libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) {
+ /* Switching here to the machine "pc" which does not add
+ * the xen-platform device instead of the default "xenfv"
machine.
+ */
+ flexarray_append(dm_args, "pc,accel=xen");
+ } else {
+ flexarray_append(dm_args, "xenfv");
+ }
for (i = 0; b_info->extra_hvm && b_info->extra_hvm[i] !=
NULL; i++)
flexarray_append(dm_args, b_info->extra_hvm[i]);
break;
--
Anthony PERARD
Wednesday, November 27, 2013, 7:21:33 PM, you wrote:> Hi,> Here is a little patch that attempt to fix the issue regarding > xen_platform_pci=0 not been handled.> There is one patch left from the previous version. The patch that was adding > qemu_machine_override have been removed as it is unnecessary. If someone wants > to change the -machine, it can always add it to device_model_args_hvm, as QEMU > appear to use the last one.> Regards,> Anthony PERARD (1): > libxl: Handle xen_platform_pci=0 case with qemu-xen.> tools/libxl/libxl_dm.c | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-)Hi Anthony, I tried your patch, but qemu fails when xen_platform_pci=0 (still boots fine with xen_platform_pci=1). The same guest + config boots fine when using qemu-xen-traditional with xen_platform_pci=0 or xen_platform_pci=1 (after Konrad''s kernel patch is applied) I can''t pinpoint why qemu doesn''t want to start .. from the verbose output from xl create: ~# xl -vvvvvvvv create /etc/xen/domU/production/xbmc.cfg Parsing config from /etc/xen/domU/production/xbmc.cfg libxl: debug: libxl_create.c:1296:do_domain_create: ao 0x22b1ed0: create: how=(nil) callback=(nil) poller=0x22b1f30 libxl: debug: libxl_device.c:251:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=unknown libxl: debug: libxl_device.c:286:libxl__device_disk_set_backend: Disk vdev=hda, using backend phy libxl: debug: libxl_create.c:740: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:607:libxl__ev_xswatch_deregister: watch w=0x22b22b8: deregister unregistered 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->000000003f800000 ENTRY ADDRESS: 0000000000100000 xc: detail: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000001fb 1GB PAGES: 0x0000000000000000 xc: detail: elf_load_binary: phdr 0 at 0x7fbf4e4a1000 -> 0x7fbf4e536e2d libxl: debug: libxl_device.c:251:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=phy libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch w=0x22b3728 wpath=/local/domain/0/backend/vbd/20/768/state token=3/0: register slotnum=3 libxl: debug: libxl_create.c:1310:do_domain_create: ao 0x22b1ed0: inprogress: poller=0x22b1f30, flags=i libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x22b3728 wpath=/local/domain/0/backend/vbd/20/768/state token=3/0: event epath=/local/domain/0/backend/vbd/20/768/state libxl: debug: libxl_event.c:646:devstate_watch_callback: backend /local/domain/0/backend/vbd/20/768/state wanted state 2 still waiting state 1 libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x22b3728 wpath=/local/domain/0/backend/vbd/20/768/state token=3/0: event epath=/local/domain/0/backend/vbd/20/768/state libxl: debug: libxl_event.c:642:devstate_watch_callback: backend /local/domain/0/backend/vbd/20/768/state wanted state 2 ok libxl: debug: libxl_event.c:595:libxl__ev_xswatch_deregister: watch w=0x22b3728 wpath=/local/domain/0/backend/vbd/20/768/state token=3/0: deregister slotnum=3 libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch w=0x22b3728: deregister unregistered libxl: debug: libxl_device.c:1022:device_hotplug: calling hotplug script: /etc/xen/scripts/block add libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch w=0x22b37b0: deregister unregistered libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch w=0x22b37b0: deregister unregistered libxl: debug: libxl_dm.c:1267:libxl__spawn_local_dm: Spawning device-model /usr/local/lib/xen/bin/qemu-system-i386 with arguments: libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: /usr/local/lib/xen/bin/qemu-system-i386 libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -xen-domid libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: 20 libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -chardev libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-20,server,nowait libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -mon libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: chardev=libxl-cmd,mode=control libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -nodefaults libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -name libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: xbmc libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -vnc libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: 172.16.1.1:9,password,to=99 libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -serial libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: pty libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -device libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: cirrus-vga libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -global libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: vga.vram_size_mb=8 libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -boot libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: order=c libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -usb libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -usbdevice libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: tablet libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -smp libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: 2,maxcpus=2 libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -device libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: e1000,id=nic0,netdev=net0,mac=00:16:3a:c6:76:65 libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -netdev libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: type=tap,id=net0,ifname=vif20.0-emu,script=no,downscript=no libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -machine libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: pc,accel=xen libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -m libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: 1016 libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -drive libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: file=/dev/xen_vms/xbmc,if=ide,index=0,media=disk,format=raw,cache=writeback libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch w=0x22b24f0 wpath=/local/domain/0/device-model/20/state token=3/1: register slotnum=3 libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x22b24f0 wpath=/local/domain/0/device-model/20/state token=3/1: event epath=/local/domain/0/device-model/20/state libxl: debug: libxl_event.c:595:libxl__ev_xswatch_deregister: watch w=0x22b24f0 wpath=/local/domain/0/device-model/20/state token=3/1: deregister slotnum=3 libxl: error: libxl_dm.c:1335:device_model_spawn_outcome: domain 20 device model: spawn failed (rc=-3) libxl: error: libxl_create.c:1140:domcreate_devmodel_started: device model did not start: -3 libxl: error: libxl_dm.c:1439:kill_device_model: Device Model already exited libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch w=0x22b07e8 wpath=/local/domain/0/backend/vbd/20/768/state token=3/2: register slotnum=3 libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x22b07e8 wpath=/local/domain/0/backend/vbd/20/768/state token=3/2: event epath=/local/domain/0/backend/vbd/20/768/state libxl: debug: libxl_event.c:642:devstate_watch_callback: backend /local/domain/0/backend/vbd/20/768/state wanted state 6 ok libxl: debug: libxl_event.c:595:libxl__ev_xswatch_deregister: watch w=0x22b07e8 wpath=/local/domain/0/backend/vbd/20/768/state token=3/2: deregister slotnum=3 libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch w=0x22b07e8: deregister unregistered libxl: debug: libxl_device.c:1022:device_hotplug: calling hotplug script: /etc/xen/scripts/block remove libxl: debug: libxl_event.c:472:watchfd_callback: watch epath=/local/domain/0/backend/vbd/20/768/state token=3/2: empty slot libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch w=0x22b0870: deregister unregistered libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch w=0x22b0870: deregister unregistered libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch w=0x22b0b90: deregister unregistered libxl: debug: libxl_event.c:1560:libxl__ao_complete: ao 0x22b1ed0: complete, rc=-3 libxl: debug: libxl_event.c:1532:libxl__ao__destroy: ao 0x22b1ed0: destroy xc: debug: hypercall buffer: total allocations:700 total releases:700 xc: debug: hypercall buffer: current allocations:0 maximum allocations:2 xc: debug: hypercall buffer: cache current size:2 xc: debug: hypercall buffer: cache hits:696 misses:2 toobig:2 -- Sander
> -----Original Message----- > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > bounces@lists.xen.org] On Behalf Of Sander Eikelenboom > Sent: 27 November 2013 23:04 > To: Anthony Perard > Cc: Ian Jackson; Stefano Stabellini; Ian Campbell; Xen Devel > Subject: Re: [Xen-devel] [PATCH v2] Handle xen_platform_pci=0 case > > > Wednesday, November 27, 2013, 7:21:33 PM, you wrote: > > > Hi, > > > Here is a little patch that attempt to fix the issue regarding > > xen_platform_pci=0 not been handled. > > > There is one patch left from the previous version. The patch that was > adding > > qemu_machine_override have been removed as it is unnecessary. If > someone wants > > to change the -machine, it can always add it to device_model_args_hvm, as > QEMU > > appear to use the last one. > > > Regards, > > > Anthony PERARD (1): > > libxl: Handle xen_platform_pci=0 case with qemu-xen. > > > tools/libxl/libxl_dm.c | 12 ++++++++++-- > > 1 file changed, 10 insertions(+), 2 deletions(-) > > > Hi Anthony, > > I tried your patch, but qemu fails when xen_platform_pci=0 (still boots fine > with xen_platform_pci=1). > > The same guest + config boots fine when using qemu-xen-traditional with > xen_platform_pci=0 or xen_platform_pci=1 > (after Konrad''s kernel patch is applied) > > I can''t pinpoint why qemu doesn''t want to start .. from the verbose output > from xl create: > > > ~# xl -vvvvvvvv create /etc/xen/domU/production/xbmc.cfg > Parsing config from /etc/xen/domU/production/xbmc.cfg > libxl: debug: libxl_create.c:1296:do_domain_create: ao 0x22b1ed0: create: > how=(nil) callback=(nil) poller=0x22b1f30 > libxl: debug: libxl_device.c:251:libxl__device_disk_set_backend: Disk > vdev=hda spec.backend=unknown > libxl: debug: libxl_device.c:286:libxl__device_disk_set_backend: Disk > vdev=hda, using backend phy > libxl: debug: libxl_create.c:740: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:607:libxl__ev_xswatch_deregister: watch > w=0x22b22b8: deregister unregistered > 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->000000003f800000 > ENTRY ADDRESS: 0000000000100000 > xc: detail: PHYSICAL MEMORY ALLOCATION: > 4KB PAGES: 0x0000000000000200 > 2MB PAGES: 0x00000000000001fb > 1GB PAGES: 0x0000000000000000 > xc: detail: elf_load_binary: phdr 0 at 0x7fbf4e4a1000 -> 0x7fbf4e536e2d > libxl: debug: libxl_device.c:251:libxl__device_disk_set_backend: Disk > vdev=hda spec.backend=phy > libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch > w=0x22b3728 wpath=/local/domain/0/backend/vbd/20/768/state > token=3/0: register slotnum=3 > libxl: debug: libxl_create.c:1310:do_domain_create: ao 0x22b1ed0: > inprogress: poller=0x22b1f30, flags=i > libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x22b3728 > wpath=/local/domain/0/backend/vbd/20/768/state token=3/0: event > epath=/local/domain/0/backend/vbd/20/768/state > libxl: debug: libxl_event.c:646:devstate_watch_callback: backend > /local/domain/0/backend/vbd/20/768/state wanted state 2 still waiting state > 1 > libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x22b3728 > wpath=/local/domain/0/backend/vbd/20/768/state token=3/0: event > epath=/local/domain/0/backend/vbd/20/768/state > libxl: debug: libxl_event.c:642:devstate_watch_callback: backend > /local/domain/0/backend/vbd/20/768/state wanted state 2 ok > libxl: debug: libxl_event.c:595:libxl__ev_xswatch_deregister: watch > w=0x22b3728 wpath=/local/domain/0/backend/vbd/20/768/state > token=3/0: deregister slotnum=3 > libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch > w=0x22b3728: deregister unregistered > libxl: debug: libxl_device.c:1022:device_hotplug: calling hotplug script: > /etc/xen/scripts/block add > libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch > w=0x22b37b0: deregister unregistered > libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch > w=0x22b37b0: deregister unregistered > libxl: debug: libxl_dm.c:1267:libxl__spawn_local_dm: Spawning device- > model /usr/local/lib/xen/bin/qemu-system-i386 with arguments: > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: > /usr/local/lib/xen/bin/qemu-system-i386 > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -xen-domid > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: 20 > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -chardev > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: socket,id=libxl- > cmd,path=/var/run/xen/qmp-libxl-20,server,nowait > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -mon > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: chardev=libxl- > cmd,mode=control > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -nodefaults > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -name > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: xbmc > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -vnc > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: > 172.16.1.1:9,password,to=99 > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -serial > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: pty > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -device > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: cirrus-vga > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -global > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: vga.vram_size_mb=8 > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -boot > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: order=c > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -usb > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -usbdevice > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: tablet > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -smp > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: 2,maxcpus=2 > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -device > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: > e1000,id=nic0,netdev=net0,mac=00:16:3a:c6:76:65 > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -netdev > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: > type=tap,id=net0,ifname=vif20.0-emu,script=no,downscript=no > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -machine > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: pc,accel=xen > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -mThis doesn''t look right. -m needs an argument and -machine has already been specified anyway.> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: 1016 > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -drive > libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: > file=/dev/xen_vms/xbmc,if=ide,index=0,media=disk,format=raw,cache=wri > teback > libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch > w=0x22b24f0 wpath=/local/domain/0/device-model/20/state token=3/1: > register slotnum=3 > libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x22b24f0 > wpath=/local/domain/0/device-model/20/state token=3/1: event > epath=/local/domain/0/device-model/20/state > libxl: debug: libxl_event.c:595:libxl__ev_xswatch_deregister: watch > w=0x22b24f0 wpath=/local/domain/0/device-model/20/state token=3/1: > deregister slotnum=3 > libxl: error: libxl_dm.c:1335:device_model_spawn_outcome: domain 20 > device model: spawn failed (rc=-3)And this is where libxl is telling you qemu refused to start. Paul> libxl: error: libxl_create.c:1140:domcreate_devmodel_started: device model > did not start: -3 > libxl: error: libxl_dm.c:1439:kill_device_model: Device Model already exited > libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch > w=0x22b07e8 wpath=/local/domain/0/backend/vbd/20/768/state > token=3/2: register slotnum=3 > libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x22b07e8 > wpath=/local/domain/0/backend/vbd/20/768/state token=3/2: event > epath=/local/domain/0/backend/vbd/20/768/state > libxl: debug: libxl_event.c:642:devstate_watch_callback: backend > /local/domain/0/backend/vbd/20/768/state wanted state 6 ok > libxl: debug: libxl_event.c:595:libxl__ev_xswatch_deregister: watch > w=0x22b07e8 wpath=/local/domain/0/backend/vbd/20/768/state > token=3/2: deregister slotnum=3 > libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch > w=0x22b07e8: deregister unregistered > libxl: debug: libxl_device.c:1022:device_hotplug: calling hotplug script: > /etc/xen/scripts/block remove > libxl: debug: libxl_event.c:472:watchfd_callback: watch > epath=/local/domain/0/backend/vbd/20/768/state token=3/2: empty slot > libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch > w=0x22b0870: deregister unregistered > libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch > w=0x22b0870: deregister unregistered > libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch > w=0x22b0b90: deregister unregistered > libxl: debug: libxl_event.c:1560:libxl__ao_complete: ao 0x22b1ed0: > complete, rc=-3 > libxl: debug: libxl_event.c:1532:libxl__ao__destroy: ao 0x22b1ed0: destroy > xc: debug: hypercall buffer: total allocations:700 total releases:700 > xc: debug: hypercall buffer: current allocations:0 maximum allocations:2 > xc: debug: hypercall buffer: cache current size:2 > xc: debug: hypercall buffer: cache hits:696 misses:2 toobig:2 > > -- > Sander > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
Thursday, November 28, 2013, 10:34:58 AM, you wrote:>> -----Original Message----- >> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- >> bounces@lists.xen.org] On Behalf Of Sander Eikelenboom >> Sent: 27 November 2013 23:04 >> To: Anthony Perard >> Cc: Ian Jackson; Stefano Stabellini; Ian Campbell; Xen Devel >> Subject: Re: [Xen-devel] [PATCH v2] Handle xen_platform_pci=0 case >> >> >> Wednesday, November 27, 2013, 7:21:33 PM, you wrote: >> >> > Hi, >> >> > Here is a little patch that attempt to fix the issue regarding >> > xen_platform_pci=0 not been handled. >> >> > There is one patch left from the previous version. The patch that was >> adding >> > qemu_machine_override have been removed as it is unnecessary. If >> someone wants >> > to change the -machine, it can always add it to device_model_args_hvm, as >> QEMU >> > appear to use the last one. >> >> > Regards, >> >> > Anthony PERARD (1): >> > libxl: Handle xen_platform_pci=0 case with qemu-xen. >> >> > tools/libxl/libxl_dm.c | 12 ++++++++++-- >> > 1 file changed, 10 insertions(+), 2 deletions(-) >> >> >> Hi Anthony, >> >> I tried your patch, but qemu fails when xen_platform_pci=0 (still boots fine >> with xen_platform_pci=1). >> >> The same guest + config boots fine when using qemu-xen-traditional with >> xen_platform_pci=0 or xen_platform_pci=1 >> (after Konrad''s kernel patch is applied) >> >> I can''t pinpoint why qemu doesn''t want to start .. from the verbose output >> from xl create: >> >> >> ~# xl -vvvvvvvv create /etc/xen/domU/production/xbmc.cfg >> Parsing config from /etc/xen/domU/production/xbmc.cfg >> libxl: debug: libxl_create.c:1296:do_domain_create: ao 0x22b1ed0: create: >> how=(nil) callback=(nil) poller=0x22b1f30 >> libxl: debug: libxl_device.c:251:libxl__device_disk_set_backend: Disk >> vdev=hda spec.backend=unknown >> libxl: debug: libxl_device.c:286:libxl__device_disk_set_backend: Disk >> vdev=hda, using backend phy >> libxl: debug: libxl_create.c:740: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:607:libxl__ev_xswatch_deregister: watch >> w=0x22b22b8: deregister unregistered >> 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->000000003f800000 >> ENTRY ADDRESS: 0000000000100000 >> xc: detail: PHYSICAL MEMORY ALLOCATION: >> 4KB PAGES: 0x0000000000000200 >> 2MB PAGES: 0x00000000000001fb >> 1GB PAGES: 0x0000000000000000 >> xc: detail: elf_load_binary: phdr 0 at 0x7fbf4e4a1000 -> 0x7fbf4e536e2d >> libxl: debug: libxl_device.c:251:libxl__device_disk_set_backend: Disk >> vdev=hda spec.backend=phy >> libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch >> w=0x22b3728 wpath=/local/domain/0/backend/vbd/20/768/state >> token=3/0: register slotnum=3 >> libxl: debug: libxl_create.c:1310:do_domain_create: ao 0x22b1ed0: >> inprogress: poller=0x22b1f30, flags=i >> libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x22b3728 >> wpath=/local/domain/0/backend/vbd/20/768/state token=3/0: event >> epath=/local/domain/0/backend/vbd/20/768/state >> libxl: debug: libxl_event.c:646:devstate_watch_callback: backend >> /local/domain/0/backend/vbd/20/768/state wanted state 2 still waiting state >> 1 >> libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x22b3728 >> wpath=/local/domain/0/backend/vbd/20/768/state token=3/0: event >> epath=/local/domain/0/backend/vbd/20/768/state >> libxl: debug: libxl_event.c:642:devstate_watch_callback: backend >> /local/domain/0/backend/vbd/20/768/state wanted state 2 ok >> libxl: debug: libxl_event.c:595:libxl__ev_xswatch_deregister: watch >> w=0x22b3728 wpath=/local/domain/0/backend/vbd/20/768/state >> token=3/0: deregister slotnum=3 >> libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch >> w=0x22b3728: deregister unregistered >> libxl: debug: libxl_device.c:1022:device_hotplug: calling hotplug script: >> /etc/xen/scripts/block add >> libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch >> w=0x22b37b0: deregister unregistered >> libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch >> w=0x22b37b0: deregister unregistered >> libxl: debug: libxl_dm.c:1267:libxl__spawn_local_dm: Spawning device- >> model /usr/local/lib/xen/bin/qemu-system-i386 with arguments: >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: >> /usr/local/lib/xen/bin/qemu-system-i386 >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -xen-domid >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: 20 >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -chardev >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: socket,id=libxl- >> cmd,path=/var/run/xen/qmp-libxl-20,server,nowait >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -mon >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: chardev=libxl- >> cmd,mode=control >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -nodefaults >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -name >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: xbmc >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -vnc >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: >> 172.16.1.1:9,password,to=99 >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -serial >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: pty >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -device >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: cirrus-vga >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -global >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: vga.vram_size_mb=8 >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -boot >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: order=c >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -usb >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -usbdevice >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: tablet >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -smp >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: 2,maxcpus=2 >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -device >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: >> e1000,id=nic0,netdev=net0,mac=00:16:3a:c6:76:65 >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -netdev >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: >> type=tap,id=net0,ifname=vif20.0-emu,script=no,downscript=no >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -machine >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: pc,accel=xen >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -m> This doesn''t look right. -m needs an argument and -machine has already been specified anyway.-m is for specifying memory, which value is specified (1016) -M is the short option for the machine, so it should be ok ..>> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: 1016 >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -drive >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: >> file=/dev/xen_vms/xbmc,if=ide,index=0,media=disk,format=raw,cache=wri >> teback >> libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch >> w=0x22b24f0 wpath=/local/domain/0/device-model/20/state token=3/1: >> register slotnum=3 >> libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x22b24f0 >> wpath=/local/domain/0/device-model/20/state token=3/1: event >> epath=/local/domain/0/device-model/20/state >> libxl: debug: libxl_event.c:595:libxl__ev_xswatch_deregister: watch >> w=0x22b24f0 wpath=/local/domain/0/device-model/20/state token=3/1: >> deregister slotnum=3 >> libxl: error: libxl_dm.c:1335:device_model_spawn_outcome: domain 20 >> device model: spawn failed (rc=-3)> And this is where libxl is telling you qemu refused to start.Yes .. but it doesn''t record *why* qemu refused to start, which would perhapds be handy to log.> Paul>> libxl: error: libxl_create.c:1140:domcreate_devmodel_started: device model >> did not start: -3 >> libxl: error: libxl_dm.c:1439:kill_device_model: Device Model already exited >> libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch >> w=0x22b07e8 wpath=/local/domain/0/backend/vbd/20/768/state >> token=3/2: register slotnum=3 >> libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x22b07e8 >> wpath=/local/domain/0/backend/vbd/20/768/state token=3/2: event >> epath=/local/domain/0/backend/vbd/20/768/state >> libxl: debug: libxl_event.c:642:devstate_watch_callback: backend >> /local/domain/0/backend/vbd/20/768/state wanted state 6 ok >> libxl: debug: libxl_event.c:595:libxl__ev_xswatch_deregister: watch >> w=0x22b07e8 wpath=/local/domain/0/backend/vbd/20/768/state >> token=3/2: deregister slotnum=3 >> libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch >> w=0x22b07e8: deregister unregistered >> libxl: debug: libxl_device.c:1022:device_hotplug: calling hotplug script: >> /etc/xen/scripts/block remove >> libxl: debug: libxl_event.c:472:watchfd_callback: watch >> epath=/local/domain/0/backend/vbd/20/768/state token=3/2: empty slot >> libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch >> w=0x22b0870: deregister unregistered >> libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch >> w=0x22b0870: deregister unregistered >> libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch >> w=0x22b0b90: deregister unregistered >> libxl: debug: libxl_event.c:1560:libxl__ao_complete: ao 0x22b1ed0: >> complete, rc=-3 >> libxl: debug: libxl_event.c:1532:libxl__ao__destroy: ao 0x22b1ed0: destroy >> xc: debug: hypercall buffer: total allocations:700 total releases:700 >> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2 >> xc: debug: hypercall buffer: cache current size:2 >> xc: debug: hypercall buffer: cache hits:696 misses:2 toobig:2 >> >> -- >> Sander >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel
Ian Campbell
2013-Nov-28 09:44 UTC
Re: [PATCH v2] libxl: Handle xen_platform_pci=0 case with qemu-xen.
On Wed, 2013-11-27 at 18:21 +0000, Anthony PERARD wrote:> This should result in QEMU *not* adding the xen-platform device. > > Since QEMU 1.6, this can be achieved by using a different qemu machine. > The one used by libxl is "xenfv", but using QEMU >=1.6 with "-machine > pc,accel=xen" works as well with only one difference compared to > "xenfv", there is no xen-platform device. > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> > --- > tools/libxl/libxl_dm.c | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c > index be39a62..ea773b3 100644 > --- a/tools/libxl/libxl_dm.c > +++ b/tools/libxl/libxl_dm.c > @@ -608,7 +608,8 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc, > } > for (i = 0; b_info->extra && b_info->extra[i] != NULL; i++) > flexarray_append(dm_args, b_info->extra[i]); > - flexarray_append(dm_args, "-M"); > + > + flexarray_append(dm_args, "-machine");I trust that -M and -machine are synonyms which go back at least as far as the versions of qemu we care about? If so then: Acked-by: Ian Campbell <ian.campbell@citrix.com> I presume that xen_platform_pci=0 will simply fail with a qemu < 1.6? Perhaps it is worth mentioning this in the xl.cfg man page?> switch (b_info->type) { > case LIBXL_DOMAIN_TYPE_PV: > flexarray_append(dm_args, "xenpv"); > @@ -616,7 +617,14 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc, > flexarray_append(dm_args, b_info->extra_pv[i]); > break; > case LIBXL_DOMAIN_TYPE_HVM: > - flexarray_append(dm_args, "xenfv"); > + if (!libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) { > + /* Switching here to the machine "pc" which does not add > + * the xen-platform device instead of the default "xenfv" machine. > + */ > + flexarray_append(dm_args, "pc,accel=xen"); > + } else { > + flexarray_append(dm_args, "xenfv"); > + } > for (i = 0; b_info->extra_hvm && b_info->extra_hvm[i] != NULL; i++) > flexarray_append(dm_args, b_info->extra_hvm[i]); > break;
On Thu, 2013-11-28 at 10:40 +0100, Sander Eikelenboom wrote:> >> libxl: error: libxl_dm.c:1335:device_model_spawn_outcome: domain 20 > >> device model: spawn failed (rc=-3) > > > And this is where libxl is telling you qemu refused to start. > > Yes .. but it doesn''t record *why* qemu refused to start, which would > perhapds be handy to log.Did you look in the qemu log? Perhaps we should add a log message here directing people to the appropriate log file? Ian.
On Thu, 2013-11-28 at 00:04 +0100, Sander Eikelenboom wrote:> I can''t pinpoint why qemu doesn''t want to startAre you using qemu >= 1.6? I think a default xen-unstable build will still be picking up something older (cf. Anthony''s patch yesterday to update Config.mk) Ian.
Thursday, November 28, 2013, 10:45:56 AM, you wrote:> On Thu, 2013-11-28 at 10:40 +0100, Sander Eikelenboom wrote: >> >> libxl: error: libxl_dm.c:1335:device_model_spawn_outcome: domain 20 >> >> device model: spawn failed (rc=-3) >> >> > And this is where libxl is telling you qemu refused to start. >> >> Yes .. but it doesn''t record *why* qemu refused to start, which would >> perhapds be handy to log.> Did you look in the qemu log?Yes .. and that still has the general problem of being completely non-verbose for qemu-xen. But that''s perhaps depending on taste (i like verbose log files .. especially for a debug build) So from qemu-dm-xmbc.log: char device redirected to /dev/pts/19 And xl-xbmc.log only seems to have what -vvvvv also showed.> Perhaps we should add a log message here directing people to the > appropriate log file?If it would log something :-) passing through stderr of qemu (when it fails) would be nice i guess.> Ian.
> -----Original Message----- > From: Sander Eikelenboom [mailto:linux@eikelenboom.it] > Sent: 28 November 2013 09:41 > To: Paul Durrant > Cc: Anthony Perard; Ian Jackson; Stefano Stabellini; Ian Campbell; Xen Devel > Subject: Re: [Xen-devel] [PATCH v2] Handle xen_platform_pci=0 case > > > Thursday, November 28, 2013, 10:34:58 AM, you wrote: > > >> -----Original Message----- > >> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > >> bounces@lists.xen.org] On Behalf Of Sander Eikelenboom > >> Sent: 27 November 2013 23:04 > >> To: Anthony Perard > >> Cc: Ian Jackson; Stefano Stabellini; Ian Campbell; Xen Devel > >> Subject: Re: [Xen-devel] [PATCH v2] Handle xen_platform_pci=0 case > >> > >> > >> Wednesday, November 27, 2013, 7:21:33 PM, you wrote: > >> > >> > Hi, > >> > >> > Here is a little patch that attempt to fix the issue regarding > >> > xen_platform_pci=0 not been handled. > >> > >> > There is one patch left from the previous version. The patch that was > >> adding > >> > qemu_machine_override have been removed as it is unnecessary. If > >> someone wants > >> > to change the -machine, it can always add it to > device_model_args_hvm, as > >> QEMU > >> > appear to use the last one. > >> > >> > Regards, > >> > >> > Anthony PERARD (1): > >> > libxl: Handle xen_platform_pci=0 case with qemu-xen. > >> > >> > tools/libxl/libxl_dm.c | 12 ++++++++++-- > >> > 1 file changed, 10 insertions(+), 2 deletions(-) > >> > >> > >> Hi Anthony, > >> > >> I tried your patch, but qemu fails when xen_platform_pci=0 (still boots > fine > >> with xen_platform_pci=1). > >> > >> The same guest + config boots fine when using qemu-xen-traditional with > >> xen_platform_pci=0 or xen_platform_pci=1 > >> (after Konrad''s kernel patch is applied) > >> > >> I can''t pinpoint why qemu doesn''t want to start .. from the verbose > output > >> from xl create: > >> > >> > >> ~# xl -vvvvvvvv create /etc/xen/domU/production/xbmc.cfg > >> Parsing config from /etc/xen/domU/production/xbmc.cfg > >> libxl: debug: libxl_create.c:1296:do_domain_create: ao 0x22b1ed0: > create: > >> how=(nil) callback=(nil) poller=0x22b1f30 > >> libxl: debug: libxl_device.c:251:libxl__device_disk_set_backend: Disk > >> vdev=hda spec.backend=unknown > >> libxl: debug: libxl_device.c:286:libxl__device_disk_set_backend: Disk > >> vdev=hda, using backend phy > >> libxl: debug: libxl_create.c:740: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:607:libxl__ev_xswatch_deregister: watch > >> w=0x22b22b8: deregister unregistered > >> 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->000000003f800000 > >> ENTRY ADDRESS: 0000000000100000 > >> xc: detail: PHYSICAL MEMORY ALLOCATION: > >> 4KB PAGES: 0x0000000000000200 > >> 2MB PAGES: 0x00000000000001fb > >> 1GB PAGES: 0x0000000000000000 > >> xc: detail: elf_load_binary: phdr 0 at 0x7fbf4e4a1000 -> 0x7fbf4e536e2d > >> libxl: debug: libxl_device.c:251:libxl__device_disk_set_backend: Disk > >> vdev=hda spec.backend=phy > >> libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch > >> w=0x22b3728 wpath=/local/domain/0/backend/vbd/20/768/state > >> token=3/0: register slotnum=3 > >> libxl: debug: libxl_create.c:1310:do_domain_create: ao 0x22b1ed0: > >> inprogress: poller=0x22b1f30, flags=i > >> libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x22b3728 > >> wpath=/local/domain/0/backend/vbd/20/768/state token=3/0: event > >> epath=/local/domain/0/backend/vbd/20/768/state > >> libxl: debug: libxl_event.c:646:devstate_watch_callback: backend > >> /local/domain/0/backend/vbd/20/768/state wanted state 2 still waiting > state > >> 1 > >> libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x22b3728 > >> wpath=/local/domain/0/backend/vbd/20/768/state token=3/0: event > >> epath=/local/domain/0/backend/vbd/20/768/state > >> libxl: debug: libxl_event.c:642:devstate_watch_callback: backend > >> /local/domain/0/backend/vbd/20/768/state wanted state 2 ok > >> libxl: debug: libxl_event.c:595:libxl__ev_xswatch_deregister: watch > >> w=0x22b3728 wpath=/local/domain/0/backend/vbd/20/768/state > >> token=3/0: deregister slotnum=3 > >> libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch > >> w=0x22b3728: deregister unregistered > >> libxl: debug: libxl_device.c:1022:device_hotplug: calling hotplug script: > >> /etc/xen/scripts/block add > >> libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch > >> w=0x22b37b0: deregister unregistered > >> libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch > >> w=0x22b37b0: deregister unregistered > >> libxl: debug: libxl_dm.c:1267:libxl__spawn_local_dm: Spawning device- > >> model /usr/local/lib/xen/bin/qemu-system-i386 with arguments: > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: > >> /usr/local/lib/xen/bin/qemu-system-i386 > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -xen-domid > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: 20 > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -chardev > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: socket,id=libxl- > >> cmd,path=/var/run/xen/qmp-libxl-20,server,nowait > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -mon > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: chardev=libxl- > >> cmd,mode=control > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -nodefaults > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -name > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: xbmc > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -vnc > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: > >> 172.16.1.1:9,password,to=99 > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -serial > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: pty > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -device > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: cirrus-vga > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -global > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: > vga.vram_size_mb=8 > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -boot > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: order=c > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -usb > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -usbdevice > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: tablet > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -smp > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: 2,maxcpus=2 > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -device > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: > >> e1000,id=nic0,netdev=net0,mac=00:16:3a:c6:76:65 > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -netdev > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: > >> type=tap,id=net0,ifname=vif20.0-emu,script=no,downscript=no > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -machine > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: pc,accel=xen > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -m > > > This doesn''t look right. -m needs an argument and -machine has already > been specified anyway. > > -m is for specifying memory, which value is specified (1016) > -M is the short option for the machine, so it should be ok .. >Sorry, you are correct. I was misremembering. Paul> > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: 1016 > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: -drive > >> libxl: debug: libxl_dm.c:1269:libxl__spawn_local_dm: > >> > file=/dev/xen_vms/xbmc,if=ide,index=0,media=disk,format=raw,cache=wri > >> teback > >> libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch > >> w=0x22b24f0 wpath=/local/domain/0/device-model/20/state token=3/1: > >> register slotnum=3 > >> libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x22b24f0 > >> wpath=/local/domain/0/device-model/20/state token=3/1: event > >> epath=/local/domain/0/device-model/20/state > >> libxl: debug: libxl_event.c:595:libxl__ev_xswatch_deregister: watch > >> w=0x22b24f0 wpath=/local/domain/0/device-model/20/state token=3/1: > >> deregister slotnum=3 > >> libxl: error: libxl_dm.c:1335:device_model_spawn_outcome: domain 20 > >> device model: spawn failed (rc=-3) > > > And this is where libxl is telling you qemu refused to start. > > Yes .. but it doesn''t record *why* qemu refused to start, which would > perhapds be handy to log. > > > Paul > > >> libxl: error: libxl_create.c:1140:domcreate_devmodel_started: device > model > >> did not start: -3 > >> libxl: error: libxl_dm.c:1439:kill_device_model: Device Model already > exited > >> libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch > >> w=0x22b07e8 wpath=/local/domain/0/backend/vbd/20/768/state > >> token=3/2: register slotnum=3 > >> libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x22b07e8 > >> wpath=/local/domain/0/backend/vbd/20/768/state token=3/2: event > >> epath=/local/domain/0/backend/vbd/20/768/state > >> libxl: debug: libxl_event.c:642:devstate_watch_callback: backend > >> /local/domain/0/backend/vbd/20/768/state wanted state 6 ok > >> libxl: debug: libxl_event.c:595:libxl__ev_xswatch_deregister: watch > >> w=0x22b07e8 wpath=/local/domain/0/backend/vbd/20/768/state > >> token=3/2: deregister slotnum=3 > >> libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch > >> w=0x22b07e8: deregister unregistered > >> libxl: debug: libxl_device.c:1022:device_hotplug: calling hotplug script: > >> /etc/xen/scripts/block remove > >> libxl: debug: libxl_event.c:472:watchfd_callback: watch > >> epath=/local/domain/0/backend/vbd/20/768/state token=3/2: empty > slot > >> libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch > >> w=0x22b0870: deregister unregistered > >> libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch > >> w=0x22b0870: deregister unregistered > >> libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch > >> w=0x22b0b90: deregister unregistered > >> libxl: debug: libxl_event.c:1560:libxl__ao_complete: ao 0x22b1ed0: > >> complete, rc=-3 > >> libxl: debug: libxl_event.c:1532:libxl__ao__destroy: ao 0x22b1ed0: > destroy > >> xc: debug: hypercall buffer: total allocations:700 total releases:700 > >> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2 > >> xc: debug: hypercall buffer: cache current size:2 > >> xc: debug: hypercall buffer: cache hits:696 misses:2 toobig:2 > >> > >> -- > >> Sander > >> > >> > >> _______________________________________________ > >> Xen-devel mailing list > >> Xen-devel@lists.xen.org > >> http://lists.xen.org/xen-devel >
Thursday, November 28, 2013, 10:47:29 AM, you wrote:> On Thu, 2013-11-28 at 00:04 +0100, Sander Eikelenboom wrote: >> I can''t pinpoint why qemu doesn''t want to startAre you using qemu >>= 1.6? I think a default xen-unstable build will> still be picking up something older (cf. Anthony''s patch yesterday to > update Config.mk)Hrrrmm good point, #/usr/local/lib/xen/bin/qemu-system-i386 --version QEMU emulator version 1.3.1, Copyright (c) 2003-2008 Fabrice Bellard Config.mk and git log in the tree give commit 1c514a7734b7f98625a0d18d5e8ee7581f26e50c Much older> Ian.
Il 27/11/2013 19:21, Anthony PERARD ha scritto:> Hi, > > Here is a little patch that attempt to fix the issue regarding > xen_platform_pci=0 not been handled. > > There is one patch left from the previous version. The patch that was adding > qemu_machine_override have been removed as it is unnecessary. If someone wants > to change the -machine, it can always add it to device_model_args_hvm, as QEMU > appear to use the last one. > > Regards, > > Anthony PERARD (1): > libxl: Handle xen_platform_pci=0 case with qemu-xen. > > tools/libxl/libxl_dm.c | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) >The patch seems good and is working, the problem of kernel panic on hvm linux domU with xen_platform_pci=0 seems problem of xen modules kernel side. I think that xen modules of linux kernel need to be fixed and/or improved (with backports to lts kernel versions). Probably xen modules can cause an issue also on other case, for example this kernel problem with spice vdagent where I not found solution for now: http://lists.freedesktop.org/archives/spice-devel/2013-October/015185.html I also tried xen_platform_pci=0 on windows 7 with gplpv installed and gave blu screen, this should be windows problem, is know that is not adactive and give blu screen also on phisical hardware when mainly components change. Without gplpv windows 7 boots also with xen_platform_pci=0. Probably I also found that with xen_platform_pci=0 seems that solve qxl "refresh problem" on windows. I''ll try to further understand what xen cause conflicts or unforeseen cases.
Thursday, November 28, 2013, 10:47:29 AM, you wrote:> On Thu, 2013-11-28 at 00:04 +0100, Sander Eikelenboom wrote: >> I can''t pinpoint why qemu doesn''t want to startAre you using qemu >>= 1.6? I think a default xen-unstable build will> still be picking up something older (cf. Anthony''s patch yesterday to > update Config.mk)So it''s probably still missing these patches from paul enabling the whole "accel=xen" option for the machine type. http://www.gossamer-threads.com/lists/xen/devel/286896> Ian.
Il 28/11/2013 11:04, Sander Eikelenboom ha scritto:> Thursday, November 28, 2013, 10:47:29 AM, you wrote: > >> On Thu, 2013-11-28 at 00:04 +0100, Sander Eikelenboom wrote: >>> I can''t pinpoint why qemu doesn''t want to start > Are you using qemu >>= 1.6? I think a default xen-unstable build will >> still be picking up something older (cf. Anthony''s patch yesterday to >> update Config.mk) > So it''s probably still missing these patches from paul enabling > the whole "accel=xen" option for the machine type. > > http://www.gossamer-threads.com/lists/xen/devel/286896This serie is included on upstream qemu 1.6: http://git.qemu.org/?p=qemu.git;a=commit;h=1e5b86804ca34913cf5bec5c1240659645774a4e>> Ian. > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
Anthony PERARD
2013-Nov-28 11:19 UTC
Re: [PATCH v2] libxl: Handle xen_platform_pci=0 case with qemu-xen.
On Thu, Nov 28, 2013 at 09:44:13AM +0000, Ian Campbell wrote:> On Wed, 2013-11-27 at 18:21 +0000, Anthony PERARD wrote: > > This should result in QEMU *not* adding the xen-platform device. > > > > Since QEMU 1.6, this can be achieved by using a different qemu machine. > > The one used by libxl is "xenfv", but using QEMU >=1.6 with "-machine > > pc,accel=xen" works as well with only one difference compared to > > "xenfv", there is no xen-platform device. > > > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> > > --- > > tools/libxl/libxl_dm.c | 12 ++++++++++-- > > 1 file changed, 10 insertions(+), 2 deletions(-) > > > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c > > index be39a62..ea773b3 100644 > > --- a/tools/libxl/libxl_dm.c > > +++ b/tools/libxl/libxl_dm.c > > @@ -608,7 +608,8 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc, > > } > > for (i = 0; b_info->extra && b_info->extra[i] != NULL; i++) > > flexarray_append(dm_args, b_info->extra[i]); > > - flexarray_append(dm_args, "-M"); > > + > > + flexarray_append(dm_args, "-machine"); > > I trust that -M and -machine are synonyms which go back at least as far > as the versions of qemu we care about?There are not really synonyms, but you can replace -M by -machine, since 2 years ago, or QEMU 0.15 it''s look like.> If so then: > Acked-by: Ian Campbell <ian.campbell@citrix.com> > > I presume that xen_platform_pci=0 will simply fail with a qemu < 1.6? > Perhaps it is worth mentioning this in the xl.cfg man page?Yes, I''ll prepare a patch. -- Anthony PERARD
Thursday, November 28, 2013, 11:11:18 AM, you wrote:> Il 28/11/2013 11:04, Sander Eikelenboom ha scritto: >> Thursday, November 28, 2013, 10:47:29 AM, you wrote: >> >>> On Thu, 2013-11-28 at 00:04 +0100, Sander Eikelenboom wrote: >>>> I can''t pinpoint why qemu doesn''t want to start >> Are you using qemu >>= 1.6? I think a default xen-unstable build will >>> still be picking up something older (cf. Anthony''s patch yesterday to >>> update Config.mk) >> So it''s probably still missing these patches from paul enabling >> the whole "accel=xen" option for the machine type. >> >> http://www.gossamer-threads.com/lists/xen/devel/286896> This serie is included on upstream qemu 1.6: > http://git.qemu.org/?p=qemu.git;a=commit;h=1e5b86804ca34913cf5bec5c1240659645774a4eJust build with qemu-upstream (which has a just released 1.7.0) and it worked with upstream. -- Sander>>> Ian. >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel
Il 28/11/2013 11:03, Fabio Fantoni ha scritto:> Il 27/11/2013 19:21, Anthony PERARD ha scritto: >> Hi, >> >> Here is a little patch that attempt to fix the issue regarding >> xen_platform_pci=0 not been handled. >> >> There is one patch left from the previous version. The patch that was >> adding >> qemu_machine_override have been removed as it is unnecessary. If >> someone wants >> to change the -machine, it can always add it to >> device_model_args_hvm, as QEMU >> appear to use the last one. >> >> Regards, >> >> Anthony PERARD (1): >> libxl: Handle xen_platform_pci=0 case with qemu-xen. >> >> tools/libxl/libxl_dm.c | 12 ++++++++++-- >> 1 file changed, 10 insertions(+), 2 deletions(-) >> > > The patch seems good and is working, the problem of kernel panic on > hvm linux domU with xen_platform_pci=0 seems problem of xen modules > kernel side. > I think that xen modules of linux kernel need to be fixed and/or > improved (with backports to lts kernel versions). > Probably xen modules can cause an issue also on other case, for > example this kernel problem with spice vdagent where I not found > solution for now: > http://lists.freedesktop.org/archives/spice-devel/2013-October/015185.html > > > I also tried xen_platform_pci=0 on windows 7 with gplpv installed and > gave blu screen, this should be windows problem, is know that is not > adactive and give blu screen also on phisical hardware when mainly > components change. > Without gplpv windows 7 boots also with xen_platform_pci=0. > Probably I also found that with xen_platform_pci=0 seems that solve > qxl "refresh problem" on windows. > I''ll try to further understand what xen cause conflicts or unforeseen > cases.I did another tests and I can confirm that the main big problem with qxl on windows domUs without gplpv and with xen_platform_pci=0 seems missed! Time ago I tested only removing gplpv but the problem remain. The only component missed in this case with qxl working is -device xen-platform, right? I tried to found possible cause of the qxl problem and I found this doc patch: http://lists.xen.org/archives/html/xen-devel/2013-11/msg01897.html I saw this part:> + Also the size parameter (default 0x400000) can be used to specify the > + size of the single MMIO BAR that the device exposes. This area may be > + used by drivers for mapping grant tables, etc.can be the cause of possible conflict with qxl? If not what other things can be different in the case of xen_platform_pci=0? Thanks for any reply and sorry for my bad english.
Thursday, November 28, 2013, 5:07:50 PM, you wrote:> Il 28/11/2013 11:03, Fabio Fantoni ha scritto: >> Il 27/11/2013 19:21, Anthony PERARD ha scritto: >>> Hi, >>> >>> Here is a little patch that attempt to fix the issue regarding >>> xen_platform_pci=0 not been handled. >>> >>> There is one patch left from the previous version. The patch that was >>> adding >>> qemu_machine_override have been removed as it is unnecessary. If >>> someone wants >>> to change the -machine, it can always add it to >>> device_model_args_hvm, as QEMU >>> appear to use the last one. >>> >>> Regards, >>> >>> Anthony PERARD (1): >>> libxl: Handle xen_platform_pci=0 case with qemu-xen. >>> >>> tools/libxl/libxl_dm.c | 12 ++++++++++-- >>> 1 file changed, 10 insertions(+), 2 deletions(-) >>> >> >> The patch seems good and is working, the problem of kernel panic on >> hvm linux domU with xen_platform_pci=0 seems problem of xen modules >> kernel side. >> I think that xen modules of linux kernel need to be fixed and/or >> improved (with backports to lts kernel versions). >> Probably xen modules can cause an issue also on other case, for >> example this kernel problem with spice vdagent where I not found >> solution for now: >> http://lists.freedesktop.org/archives/spice-devel/2013-October/015185.html >> >> >> I also tried xen_platform_pci=0 on windows 7 with gplpv installed and >> gave blu screen, this should be windows problem, is know that is not >> adactive and give blu screen also on phisical hardware when mainly >> components change. >> Without gplpv windows 7 boots also with xen_platform_pci=0. >> Probably I also found that with xen_platform_pci=0 seems that solve >> qxl "refresh problem" on windows. >> I''ll try to further understand what xen cause conflicts or unforeseen >> cases.perhaps the gplpv drivers suffer from the same logic als the linux kernel does (without konrad''s patch) ?> I did another tests and I can confirm that the main big problem with qxl > on windows domUs without gplpv and with xen_platform_pci=0 seems missed! > Time ago I tested only removing gplpv but the problem remain.> The only component missed in this case with qxl working is -device > xen-platform, right? > I tried to found possible cause of the qxl problem and I found this doc > patch: > http://lists.xen.org/archives/html/xen-devel/2013-11/msg01897.html > I saw this part: >> + Also the size parameter (default 0x400000) can be used to specify the >> + size of the single MMIO BAR that the device exposes. This area may be >> + used by drivers for mapping grant tables, etc. > can be the cause of possible conflict with qxl? > If not what other things can be different in the case of xen_platform_pci=0?> Thanks for any reply and sorry for my bad english.
On Thu, Nov 28, 2013 at 05:07:50PM +0100, Fabio Fantoni wrote:> Il 28/11/2013 11:03, Fabio Fantoni ha scritto: > >Il 27/11/2013 19:21, Anthony PERARD ha scritto: > >>Hi, > >> > >>Here is a little patch that attempt to fix the issue regarding > >>xen_platform_pci=0 not been handled. > >> > >>There is one patch left from the previous version. The patch that was > >>adding > >>qemu_machine_override have been removed as it is unnecessary. If someone > >>wants > >>to change the -machine, it can always add it to device_model_args_hvm, > >>as QEMU > >>appear to use the last one. > >> > >>Regards, > >> > >>Anthony PERARD (1): > >> libxl: Handle xen_platform_pci=0 case with qemu-xen. > >> > >> tools/libxl/libxl_dm.c | 12 ++++++++++-- > >> 1 file changed, 10 insertions(+), 2 deletions(-) > >> > > > >The patch seems good and is working, the problem of kernel panic on hvm > >linux domU with xen_platform_pci=0 seems problem of xen modules kernel > >side. > >I think that xen modules of linux kernel need to be fixed and/or improved > >(with backports to lts kernel versions). > >Probably xen modules can cause an issue also on other case, for example > >this kernel problem with spice vdagent where I not found solution for now: > >http://lists.freedesktop.org/archives/spice-devel/2013-October/015185.html > > > > > >I also tried xen_platform_pci=0 on windows 7 with gplpv installed and gave > >blu screen, this should be windows problem, is know that is not adactive > >and give blu screen also on phisical hardware when mainly components > >change. > >Without gplpv windows 7 boots also with xen_platform_pci=0. > >Probably I also found that with xen_platform_pci=0 seems that solve qxl > >"refresh problem" on windows. > >I''ll try to further understand what xen cause conflicts or unforeseen > >cases. > > I did another tests and I can confirm that the main big problem with qxl on > windows domUs without gplpv and with xen_platform_pci=0 seems missed! > Time ago I tested only removing gplpv but the problem remain. > > The only component missed in this case with qxl working is -device > xen-platform, right?Sorry, I don''t know. Never tryed PV driver on Windows and never tryed QXL on Windows. But I can tell you that you should not need to add "-device xen-platform" anywhere. If you xen_platform_pci=1 (or nothing), you will get the xen-platform. If you have xen_platform_pci=0, then you say you don''t want the xen-platform.> I tried to found possible cause of the qxl problem and I found this doc > patch: > http://lists.xen.org/archives/html/xen-devel/2013-11/msg01897.html > I saw this part: > >+ Also the size parameter (default 0x400000) can be used to specify the > >+ size of the single MMIO BAR that the device exposes. This area may be > >+ used by drivers for mapping grant tables, etc. > can be the cause of possible conflict with qxl? > If not what other things can be different in the case of xen_platform_pci=0?The only difference between xen_platform_pci=0 and =1 is the presence of the "xen-platform" device which is seen as a PCI device by a guest, and which is used by PV drivers. -- Anthony PERARD
Ian Campbell
2013-Nov-29 10:34 UTC
Re: [PATCH v2] libxl: Handle xen_platform_pci=0 case with qemu-xen.
On Wed, 2013-11-27 at 18:21 +0000, Anthony PERARD wrote:> This should result in QEMU *not* adding the xen-platform device. > > Since QEMU 1.6, this can be achieved by using a different qemu machine. > The one used by libxl is "xenfv", but using QEMU >=1.6 with "-machine > pc,accel=xen" works as well with only one difference compared to > "xenfv", there is no xen-platform device. > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>Applied. I wonder -- should we make a statement somewhere about the minimum supported version qemu? Similar to how we do with e.g. gcc. I suppose we would start at 1.5 since that is when support first went upstream? As time goes by we will need to take into account what version is in the various stable distros. Perhaps we should add this to the README as an optional build dependency. e.g. "Although Xen ships with an included qemu-xen you can also choose to use a system provided qemu provided it is built with Xen support and is at least version X.Y"? Ian.
Fabio Fantoni
2013-Nov-29 10:51 UTC
Re: [PATCH v2] libxl: Handle xen_platform_pci=0 case with qemu-xen.
Il 29/11/2013 11:34, Ian Campbell ha scritto:> On Wed, 2013-11-27 at 18:21 +0000, Anthony PERARD wrote: >> This should result in QEMU *not* adding the xen-platform device. >> >> Since QEMU 1.6, this can be achieved by using a different qemu machine. >> The one used by libxl is "xenfv", but using QEMU >=1.6 with "-machine >> pc,accel=xen" works as well with only one difference compared to >> "xenfv", there is no xen-platform device. >> >> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> > Applied. > > I wonder -- should we make a statement somewhere about the minimum > supported version qemu? Similar to how we do with e.g. gcc. I suppose we > would start at 1.5 since that is when support first went upstream? As > time goes by we will need to take into account what version is in the > various stable distros. > > Perhaps we should add this to the README as an optional build > dependency. e.g. "Although Xen ships with an included qemu-xen you can > also choose to use a system provided qemu provided it is built with Xen > support and is at least version X.Y"?I think is good to suggest qemu>=1.6.1 In the last months I have kept tested a lot of the newer versions of qemu upstream from upstream git (xen git was with qemu 1.3), if I remember good qemu 1.5 have an important bug with xen on some cases, solved with 1.6 but 1.6 have a critical bug with all xen hvm domUs solved with 1.6.1. With 1.6.1 I not found any critical or important xen related new bugs or regressions for now, I tested windows 7, xp and some fedora, ubuntu and debian versions as hvm domUs.> > Ian. > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
Maybe Matching Threads
- OVMF Bios Option
- Bug#776742: xen-utils-common: no support for VGA Passthrough
- xl console regression on xen-unstable
- ubuntu13.04 host and ubuntu13.04 guest how to config the pvscsi
- RESEND [Xen-unstable][Qemu-xen] HVM Guest reading of Expansion ROM from passthroughed PCI device returns data from emulated VGA rom