Xen devel - Nov 2013 - [PATCH v2] Handle xen_platform_pci=0 case

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

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:   -m
This 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

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

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 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)
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 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
> 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/286896
This 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

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=1e5b86804ca34913cf5bec5c1240659645774a4e
Just 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

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.

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