Test result of xen-unstable changeset 25259

Test result of xen-unstable changeset 25259

[Fantu]

Dom0:
Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
3.2.15-1, package blktap-dkms and all dependency packages for xen, spice and
usb redirection.
-------------------------
/etc/modules
------------
loop max_loop=64
xenfs
xen-evtchn
blktap
-------------------------
hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is
25259:0f53540494f7)
vi Makefile # removed dist-kernel to not compile kernel
vi Config.mk # test seabios unstable
PYTHON_PREFIX_ARG =
QEMU_UPSTREAM_URL ?= git://git.qemu.org/qemu.git #commit
8f473dd104f0937ce98523fa6f9de0bd845aebbe
SEABIOS_UPSTREAM_URL ?= git://git.seabios.org/seabios.git #commit
74f96123e7e37c219403b50e39dabc8e8c450948
SEABIOS_UPSTREAM_TAG ?= master
-------------------------
Added some patches:
- autoconf: add variable for pass arbitrary options to qemu upstream v3
- tools: Improve make deb
-------------------------
./configure --enable-qemuu-spice --enable-qemuu-usbredir
--enable-qemuu-debug
-------------------------
make deb

-------------------------
Recent regression:
-------------
- CRITICAL - PV domU unable to start:
With pygrub:
xl create /etc/xen/lucid.cfg
Parsing config file /etc/xen/lucid.cfg
libxl: error: libxl_create.c:603:do_domain_create: failed to run bootloader:
-3
With pv-grub:
xl create /etc/xen/lucid.cfg
Parsing config file /etc/xen/lucid.cfg
xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel:
kernel is not a bzImage: Invalid kernel
Daemon running with PID 6136
Same error also with other linux pv domU.
-------------------------

-------------------------
Old issue:
- Save/restore not working with qemu-xen
-------------
- Unable to get QXL vga working correctly and with full videoram
-------------
- On hvm domU start, domU work also this output on xl create:
libxl: error: libxl.c:3115:libxl_sched_credit_domain_set: Cpu weight out of
range, valid values are within range from 1 to 65535
-------------------------

--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

Re: Test result of xen-unstable changeset 25259

[Ian Campbell]

On Mon, 2012-05-07 at 15:12 +0100, Fantu wrote:
> Dom0:
> Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
> 3.2.15-1, package blktap-dkms and all dependency packages for xen, spice and
> usb redirection.
> -------------------------
> /etc/modules
> ------------
> loop max_loop=64
> xenfs
> xen-evtchn
> blktap
> -------------------------
> hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is
> 25259:0f53540494f7)
> vi Makefile # removed dist-kernel to not compile kernel

This should not be necessary at all. No kernel will be built, if you are
seeing kernels getting built in the default configuration then please
let me know.

> vi Config.mk # test seabios unstable

I don't think this will have any impact on any of the issues you relate
below. But also note that results with SeaBIOS other than the one
referenced by the tree would not be considered problems for Xen 4.2.

> PYTHON_PREFIX_ARG =
> QEMU_UPSTREAM_URL ?= git://git.qemu.org/qemu.git #commit
> 8f473dd104f0937ce98523fa6f9de0bd845aebbe
> SEABIOS_UPSTREAM_URL ?= git://git.seabios.org/seabios.git #commit
> 74f96123e7e37c219403b50e39dabc8e8c450948
> SEABIOS_UPSTREAM_TAG ?= master
> -------------------------
> Added some patches:
> - autoconf: add variable for pass arbitrary options to qemu upstream v3
> - tools: Improve make deb
> -------------------------
> ./configure --enable-qemuu-spice --enable-qemuu-usbredir
> --enable-qemuu-debug
> -------------------------
> make deb
> 
> -------------------------
> Recent regression:
> -------------
> - CRITICAL - PV domU unable to start:
> With pygrub:
> xl create /etc/xen/lucid.cfg
> Parsing config file /etc/xen/lucid.cfg
> libxl: error: libxl_create.c:603:do_domain_create: failed to run bootloader:
> -3
> With pv-grub:
> xl create /etc/xen/lucid.cfg
> Parsing config file /etc/xen/lucid.cfg
> xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel:
> kernel is not a bzImage: Invalid kernel
> Daemon running with PID 6136
> Same error also with other linux pv domU.

When we went through this on you last posting this seemed to be related
to the python path stuff on Ubuntu/Debian. However you don't mention
tweaking that in your setup -- are you sure you have corrected this
issue?

If this isn't the issue then please can you provide (separately) full
logs (xl cr -vvv & /var/log/xen/foo, etc) for both these cases.

> -------------------------
> 
> -------------------------
> Old issue:
> - Save/restore not working with qemu-xen

This is expected -- this support is not yet added to the tree.

> -------------
> - Unable to get QXL vga working correctly and with full videoram

I think we have now established that this is not currently a feature of
Xen. If you or Zhou Peng are interested in doing the development work
for then this is something we would likely accept as a new feature for
Xen 4.3. It's not 4.2 material though.

> -------------
> - On hvm domU start, domU work also this output on xl create:
> libxl: error: libxl.c:3115:libxl_sched_credit_domain_set: Cpu weight out of
> range, valid values are within range from 1 to 65535

I have added this one to the TODO list as a bug, hopefully someone is
looking into it.

Ian.

Re: Test result of xen-unstable changeset 25259

[Fantu]

Ian Campbell-10 wrote
> 
> When we went through this on you last posting this seemed to be related
> to the python path stuff on Ubuntu/Debian. However you don't mention
> tweaking that in your setup -- are you sure you have corrected this
> issue?
> 
> If this isn't the issue then please can you provide (separately) full
> logs (xl cr -vvv & /var/log/xen/foo, etc) for both these cases.
> 
"PYTHON_PREFIX_ARG =" in Config.mk solves python error on pygrub but not
domU pv boot error.

--------------------------------------
lucid.cfg
--------
name="lucid"
vcpus=2
memory=512
disk=['/mnt/vm/disks/lucid.disk1.xm,raw,xvda1,rw',
'/mnt/vm/disks/lucid.disk2.xm,raw,xvda2,rw']
vif=['bridge=xenbr0']
vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
bootloader = '/usr/bin/pygrub'
#kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz"
#extra = "(hd0,0)/grub/grub.cfg"
--------------------------------------

With pygrub:
--------------------------------------
xl -vvv create /etc/xen/lucid.cfg
Parsing config file /etc/xen/lucid.cfg
libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
vdev=xvda1 spec.backend=unknown
libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend
phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk
vdev=xvda1, using backend tap
libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
vdev=xvda2 spec.backend=unknown
libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend
phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk
vdev=xvda2, using backend tap
libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
vdev=xvda1 spec.backend=tap
libxl: debug: libxl.c:1689:libxl_device_disk_local_attach: locally attaching
tap disk /mnt/vm/disks/lucid.disk1.xm directly (ie without using blktap)
libxl: error: libxl_create.c:603:do_domain_create: failed to run bootloader:
-3
xc: debug: hypercall buffer: total allocations:13 total releases:13
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:10 misses:2 toobig:1
-------------------------------
xl-lucid.log seems not to be created during this xl create
--------------------------------------

With pv-grub:
--------------------------------------
xl -vvv create /etc/xen/lucid.cfg
Parsing config file /etc/xen/lucid.cfg
libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
vdev=xvda1 spec.backend=unknown
libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend
phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk
vdev=xvda1, using backend tap
libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
vdev=xvda2 spec.backend=unknown
libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend
phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk
vdev=xvda2, using backend tap
domainbuilder: detail: xc_dom_allocate: cmdline="(hd0,0)/grub/grub.cfg",
features="(null)"
domainbuilder: detail: xc_dom_kernel_file:
filename="/usr/lib/xen/boot/pv-grub-x86_64.gz"
domainbuilder: detail: xc_dom_malloc_filemap    : 978 kB
domainbuilder: detail: xc_dom_malloc            : 14277 kB
domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0xf4ac6 -> 0xdf17c6
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.2, caps xen-3.0-x86_64
xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader
... 
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... 
xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel:
kernel is not a bzImage: Invalid kernel
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... 
domainbuilder: detail: loader probe OK
xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x99ef00
xc: detail: elf_parse_binary: memory: 0x0 -> 0x99ef00
xc: detail: elf_xen_parse: __xen_guest:
"GUEST_OS=Mini-OS,XEN_VER=xen-3.0,VIRT_BASE=0x0,ELF_PADDR_OFFSET=0x0,HYPERCALL_PAGE=0x2,LOADER=generic"
xc: detail: elf_xen_parse_guest_info: GUEST_OS="Mini-OS"
xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0"
xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x0"
xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x0"
xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x2"
xc: detail: elf_xen_parse_guest_info: LOADER="generic"
xc: detail: elf_xen_addr_calc_check: addresses:
xc: detail:     virt_base        = 0x0
xc: detail:     elf_paddr_offset = 0x0
xc: detail:     virt_offset      = 0x0
xc: detail:     virt_kstart      = 0x0
xc: detail:     virt_kend        = 0x99ef00
xc: detail:     virt_entry       = 0x0
xc: detail:     p2m_base         = 0xffffffffffffffff
domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64: 0x0 ->
0x99ef00
domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages, 4k
each
domainbuilder: detail: xc_dom_mem_init: 0x20000 pages
domainbuilder: detail: xc_dom_boot_mem_init: called
domainbuilder: detail: x86_compat: guest xen-3.0-x86_64, address size 64
domainbuilder: detail: xc_dom_malloc            : 1024 kB
domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail: xc_dom_alloc_segment:   kernel       : 0x0 ->
0x99f000  (pfn 0x0 + 0x99f pages)
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x0+0x99f at
0x7f6a04b45000
xc: detail: elf_load_binary: phdr 0 at 0x0x7f6a04b45000 -> 0x0x7f6a054e3f00
domainbuilder: detail: xc_dom_alloc_segment:   phys2mach    : 0x99f000 ->
0xa9f000  (pfn 0x99f + 0x100 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x99f+0x100 at
0x7f6a04a45000
domainbuilder: detail: xc_dom_alloc_page   :   start info   : 0xa9f000 (pfn
0xa9f)
domainbuilder: detail: xc_dom_alloc_page   :   xenstore     : 0xaa0000 (pfn
0xaa0)
domainbuilder: detail: xc_dom_alloc_page   :   console      : 0xaa1000 (pfn
0xaa1)
domainbuilder: detail: nr_page_tables: 0x0000ffffffffffff/48:
0x0000000000000000 -> 0x0000ffffffffffff, 1 table(s)
domainbuilder: detail: nr_page_tables: 0x0000007fffffffff/39:
0x0000000000000000 -> 0x0000007fffffffff, 1 table(s)
domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30:
0x0000000000000000 -> 0x000000003fffffff, 1 table(s)
domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21:
0x0000000000000000 -> 0x0000000000bfffff, 6 table(s)
domainbuilder: detail: xc_dom_alloc_segment:   page tables  : 0xaa2000 ->
0xaab000  (pfn 0xaa2 + 0x9 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xaa2+0x9 at
0x7f6a04a3c000
domainbuilder: detail: xc_dom_alloc_page   :   boot stack   : 0xaab000 (pfn
0xaab)
domainbuilder: detail: xc_dom_build_image  : virt_alloc_end : 0xaac000
domainbuilder: detail: xc_dom_build_image  : virt_pgtab_end : 0xc00000
domainbuilder: detail: xc_dom_boot_image: called
domainbuilder: detail: arch_setup_bootearly: doing nothing
domainbuilder: detail: xc_dom_compat_check: supported guest type:
xen-3.0-x86_64 <= matches
domainbuilder: detail: xc_dom_compat_check: supported guest type:
xen-3.0-x86_32p
domainbuilder: detail: xc_dom_compat_check: supported guest type:
hvm-3.0-x86_32
domainbuilder: detail: xc_dom_compat_check: supported guest type:
hvm-3.0-x86_32p
domainbuilder: detail: xc_dom_compat_check: supported guest type:
hvm-3.0-x86_64
domainbuilder: detail: xc_dom_update_guest_p2m: dst 64bit, pages 0x20000
domainbuilder: detail: clear_page: pfn 0xaa1, mfn 0x33f1c8
domainbuilder: detail: clear_page: pfn 0xaa0, mfn 0x33f1c9
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xa9f+0x1 at
0x7f6a04a3b000
domainbuilder: detail: start_info_x86_64: called
domainbuilder: detail: setup_hypercall_page: vaddr=0x2000 pfn=0x2
domainbuilder: detail: domain builder memory footprint
domainbuilder: detail:    allocated
domainbuilder: detail:       malloc             : 15368 kB
domainbuilder: detail:       anon mmap          : 0 bytes
domainbuilder: detail:    mapped
domainbuilder: detail:       file mmap          : 978 kB
domainbuilder: detail:       domU mmap          : 10916 kB
domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn
0xbf111
domainbuilder: detail: shared_info_x86_64: called
domainbuilder: detail: vcpu_x86_64: called
domainbuilder: detail: vcpu_x86_64: cr3: pfn 0xaa2 mfn 0x33f1c7
domainbuilder: detail: launch_vm: called, ctxt=0x7fff4b0bd640
domainbuilder: detail: xc_dom_release: called
libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
vdev=xvda1 spec.backend=tap
libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
vdev=xvda2 spec.backend=tap
libxl: debug: libxl_dm.c:987:libxl__create_device_model: Spawning
device-model /usr/lib/xen/bin/qemu-system-i386 with arguments:
libxl: debug: libxl_dm.c:989:libxl__create_device_model:  
/usr/lib/xen/bin/qemu-system-i386
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -xen-domid
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   21
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -chardev
libxl: debug: libxl_dm.c:989:libxl__create_device_model:  
socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-21,server,nowait
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -mon
libxl: debug: libxl_dm.c:989:libxl__create_device_model:  
chardev=libxl-cmd,mode=control
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -xen-attach
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -name
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   lucid
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -vnc
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   0.0.0.0:0,to=99
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -k
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   it
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -M
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   xenpv
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -m
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   513
libxl: debug: libxl_qmp.c:692:libxl__qmp_initialize: connected to
/var/run/xen/qmp-libxl-21
libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: qmp
libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command:
'{"execute":"qmp_capabilities","id":1}'
libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return
libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command:
'{"execute":"query-chardev","id":2}'
libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return
libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command:
'{"execute":"query-vnc","id":3}'
libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return
Daemon running with PID 9230
xc: debug: hypercall buffer: total allocations:154 total releases:154
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:149 misses:2 toobig:3
-------------------------------
/var/log/xen/xl-lucid.log
-----------------------
Waiting for domain lucid (domid 21) to die [pid 9231]
libxl: debug: libxl_event.c:406:watchfd_callback: watch event:
epath=@releaseDomain token=3/0 wpath=@releaseDomain w=0x1bd0818
libxl: debug: libxl.c:806:domain_death_xswatch_callback: [evg=0x1bcd920:21]
from domid=21 nentries=1 rc=1
libxl: debug: libxl.c:817:domain_death_xswatch_callback: [evg=0x1bcd920:21]  
got=domaininfos[0] got->domain=21
libxl: debug: libxl.c:844:domain_death_xswatch_callback:  exists
shutdown_reported=0 dominf.flags=ffff0020
libxl: debug: libxl.c:810:domain_death_xswatch_callback: [evg=0] all
reported
libxl: debug: libxl.c:874:domain_death_xswatch_callback: domain death search
done
libxl: debug: libxl_event.c:406:watchfd_callback: watch event:
epath=@releaseDomain token=3/0 wpath=@releaseDomain w=0x1bd0818
libxl: debug: libxl.c:806:domain_death_xswatch_callback: [evg=0x1bcd920:21]
from domid=21 nentries=1 rc=0
libxl: debug: libxl.c:817:domain_death_xswatch_callback: [evg=0x1bcd920:21]  
got=domaininfos[0] got->domain=-1
libxl: debug: libxl.c:761:domain_death_occurred: empty list
libxl: debug: libxl.c:810:domain_death_xswatch_callback: [evg=0] all
reported
libxl: debug: libxl.c:874:domain_death_xswatch_callback: domain death search
done
Domain 21 has been destroyed.
--------------------------------------

--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153p5694297.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

Re: Test result of xen-unstable changeset 25259

[Ian Campbell]

On Tue, 2012-05-08 at 14:22 +0100, Fantu wrote:
> Ian Campbell-10 wrote
> >
> > When we went through this on you last posting this seemed to be related
> > to the python path stuff on Ubuntu/Debian. However you don't mention
> > tweaking that in your setup -- are you sure you have corrected this
> > issue?
> >
> > If this isn't the issue then please can you provide (separately) full
> > logs (xl cr -vvv & /var/log/xen/foo, etc) for both these cases.
> >
> "PYTHON_PREFIX_ARG =" in Config.mk solves python error on pygrub but not
> domU pv boot error.

Your logs seem to show the opposite -- pygrub still fails by pvgrub
works ok.

> --------------------------------------
> lucid.cfg
> --------
> name="lucid"
> vcpus=2
> memory=512
> disk=['/mnt/vm/disks/lucid.disk1.xm,raw,xvda1,rw',
> '/mnt/vm/disks/lucid.disk2.xm,raw,xvda2,rw']
> vif=['bridge=xenbr0']
> vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
> bootloader = '/usr/bin/pygrub'
> #kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz"
> #extra = "(hd0,0)/grub/grub.cfg"
> --------------------------------------
> 
> With pygrub:
> --------------------------------------
> xl -vvv create /etc/xen/lucid.cfg
> Parsing config file /etc/xen/lucid.cfg
> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
> vdev=xvda1 spec.backend=unknown
> libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend
> phy unsuitable as phys path not a block device
> libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk
> vdev=xvda1, using backend tap
> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
> vdev=xvda2 spec.backend=unknown
> libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend
> phy unsuitable as phys path not a block device
> libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk
> vdev=xvda2, using backend tap
> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
> vdev=xvda1 spec.backend=tap
> libxl: debug: libxl.c:1689:libxl_device_disk_local_attach: locally attaching
> tap disk /mnt/vm/disks/lucid.disk1.xm directly (ie without using blktap)
> libxl: error: libxl_create.c:603:do_domain_create: failed to run bootloader:
> -3

Do you still get the same error about xen.lowlevel.xc as before if you
run
	pygrub /mnt/vm/disks/lucid.disk1.xm
by hand?

Ian.

Re: Test result of xen-unstable changeset 25259

[Fantu]

Ian Campbell-10 wrote
> 
> On Tue, 2012-05-08 at 14:22 +0100, Fantu wrote:
>> Ian Campbell-10 wrote
>> >
>> > When we went through this on you last posting this seemed to be related
>> > to the python path stuff on Ubuntu/Debian. However you don't mention
>> > tweaking that in your setup -- are you sure you have corrected this
>> > issue?
>> >
>> > If this isn't the issue then please can you provide (separately) full
>> > logs (xl cr -vvv & /var/log/xen/foo, etc) for both these cases.
>> >
>> "PYTHON_PREFIX_ARG =" in Config.mk solves python error on pygrub but not
>> domU pv boot error.
> 
> Your logs seem to show the opposite -- pygrub still fails by pvgrub
> works ok.
> 
>> --------------------------------------
>> lucid.cfg
>> --------
>> name="lucid"
>> vcpus=2
>> memory=512
>> disk=['/mnt/vm/disks/lucid.disk1.xm,raw,xvda1,rw',
>> '/mnt/vm/disks/lucid.disk2.xm,raw,xvda2,rw']
>> vif=['bridge=xenbr0']
>> vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
>> bootloader = '/usr/bin/pygrub'
>> #kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz"
>> #extra = "(hd0,0)/grub/grub.cfg"
>> --------------------------------------
>> 
>> With pygrub:
>> --------------------------------------
>> xl -vvv create /etc/xen/lucid.cfg
>> Parsing config file /etc/xen/lucid.cfg
>> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
>> vdev=xvda1 spec.backend=unknown
>> libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1,
>> backend
>> phy unsuitable as phys path not a block device
>> libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk
>> vdev=xvda1, using backend tap
>> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
>> vdev=xvda2 spec.backend=unknown
>> libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2,
>> backend
>> phy unsuitable as phys path not a block device
>> libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk
>> vdev=xvda2, using backend tap
>> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
>> vdev=xvda1 spec.backend=tap
>> libxl: debug: libxl.c:1689:libxl_device_disk_local_attach: locally
>> attaching
>> tap disk /mnt/vm/disks/lucid.disk1.xm directly (ie without using blktap)
>> libxl: error: libxl_create.c:603:do_domain_create: failed to run
>> bootloader:
>> -3
> 
> Do you still get the same error about xen.lowlevel.xc as before if you
> run
> 	pygrub /mnt/vm/disks/lucid.disk1.xm
> by hand?
> 
> Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@.xen
> http://lists.xen.org/xen-devel
> 
---------------------------------------------
pygrub /mnt/vm/disks/lucid.disk1.xm 
Traceback (most recent call last):
  File "/usr/local/bin/pygrub", line 822, in <module>
    raise RuntimeError, "Unable to find partition containing kernel"
RuntimeError: Unable to find partition containing kernel
---------------------------------------------

About pv-grub I think it fails with:
... (from xl create...)
xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel:
kernel is not a bzImage: Invalid kernel
...
And after seems start as hvm domU but is not working and I must destroy it.

--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153p5694426.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

Re: Test result of xen-unstable changeset 25259

[Ian Campbell]

On Tue, 2012-05-08 at 14:38 +0100, Fantu wrote:
> ---------------------------------------------
> pygrub /mnt/vm/disks/lucid.disk1.xm 
> Traceback (most recent call last):
>   File "/usr/local/bin/pygrub", line 822, in <module>
>     raise RuntimeError, "Unable to find partition containing kernel"
> RuntimeError: Unable to find partition containing kernel

/usr/local/bin? Are you sure this is the pygrub you built and installed
just now and not some other cruft?

Are you able to identify when it last worked and run a bisect? You don't
need to do a full boot of the guest, just run pygrub manually at each
stage.

> ---------------------------------------------
> 
> About pv-grub I think it fails with:
> ... (from xl create...)
> xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel:
> kernel is not a bzImage: Invalid kernel
> ...
> And after seems start as hvm domU but is not working and I must destroy it.

I think this is just a warning (which needs to be toned down), since the
pvgrub kernel isn't a bzImage, it's a simple elf file.

Your logs show it building a Mini-OS domain, not an HVM one:
        domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ...
        domainbuilder: detail: loader probe OK
        xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x99ef00
        xc: detail: elf_parse_binary: memory: 0x0 -> 0x99ef00
        xc: detail: elf_xen_parse: __xen_guest:
        "GUEST_OS=Mini-OS,XEN_VER=xen-3.0,VIRT_BASE=0x0,ELF_PADDR_OFFSET=0x0,HYPERCALL_PAGE=0x2,LOADER=generic"
        xc: detail: elf_xen_parse_guest_info: GUEST_OS="Mini-OS"
        xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0"
        xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x0"
        xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x0"
        xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x2"
        xc: detail: elf_xen_parse_guest_info: LOADER="generic"
        xc: detail: elf_xen_addr_calc_check: addresses:
        xc: detail:     virt_base        = 0x0
        xc: detail:     elf_paddr_offset = 0x0
        xc: detail:     virt_offset      = 0x0
        xc: detail:     virt_kstart      = 0x0
        xc: detail:     virt_kend        = 0x99ef00
        xc: detail:     virt_entry       = 0x0
        xc: detail:     p2m_base         = 0xffffffffffffffff
        
I think if you investigate more closely you would find it is working, at
least as far as building an running something..

Ian

Re: Test result of xen-unstable changeset 25259

[Fantu]

Ian Campbell-10 wrote
> 
> Your logs show it building a Mini-OS domain, not an HVM one:
>         domainbuilder: detail: xc_dom_find_loader: trying ELF-generic
> loader ...
>         domainbuilder: detail: loader probe OK
>         xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x99ef00
>         xc: detail: elf_parse_binary: memory: 0x0 -> 0x99ef00
>         xc: detail: elf_xen_parse: __xen_guest:
>        
> "GUEST_OS=Mini-OS,XEN_VER=xen-3.0,VIRT_BASE=0x0,ELF_PADDR_OFFSET=0x0,HYPERCALL_PAGE=0x2,LOADER=generic"
>         xc: detail: elf_xen_parse_guest_info: GUEST_OS="Mini-OS"
>         xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0"
>         xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x0"
>         xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x0"
>         xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x2"
>         xc: detail: elf_xen_parse_guest_info: LOADER="generic"
>         xc: detail: elf_xen_addr_calc_check: addresses:
>         xc: detail:     virt_base        = 0x0
>         xc: detail:     elf_paddr_offset = 0x0
>         xc: detail:     virt_offset      = 0x0
>         xc: detail:     virt_kstart      = 0x0
>         xc: detail:     virt_kend        = 0x99ef00
>         xc: detail:     virt_entry       = 0x0
>         xc: detail:     p2m_base         = 0xffffffffffffffff
>         
> I think if you investigate more closely you would find it is working, at
> least as far as building an running something..
> 
Please try to see further in the xl create output on pv-grub test...
...
libxl: debug: libxl_dm.c:987:libxl__create_device_model: Spawning
device-model /usr/lib/xen/bin/qemu-system-i386 with arguments:
libxl: debug: libxl_dm.c:989:libxl__create_device_model:  
/usr/lib/xen/bin/qemu-system-i386
...
Is it right?

--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153p5694597.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

Re: Test result of xen-unstable changeset 25259

[Ian Campbell]

> > About pv-grub I think it fails with:
> > ... (from xl create...)
> > xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel:
> > kernel is not a bzImage: Invalid kernel
> > ...
> > And after seems start as hvm domU but is not working and I must destroy it.
> 
> I think this is just a warning (which needs to be toned down), since the
> pvgrub kernel isn't a bzImage, it's a simple elf file.

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1336485612 -3600
# Node ID 8aba3396a61a2224b7cb36046ce06bad053e956b
# Parent  2fe12fc7bf1f863487920e06589641904b3d9466
libxc: do not "panic" if a kernel is not a bzImage.

Up untul the point where we think this is a bzImage there is no point in
printing panicy messages -- some other loader will have a go (probably the
compressed ELF one)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 2fe12fc7bf1f -r 8aba3396a61a tools/libxc/xc_dom_bzimageloader.c
--- a/tools/libxc/xc_dom_bzimageloader.c	Tue May 08 14:25:27 2012 +0100
+++ b/tools/libxc/xc_dom_bzimageloader.c	Tue May 08 15:00:12 2012 +0100
@@ -575,8 +575,7 @@ static int xc_dom_probe_bzimage_kernel(s
 
     if ( dom->kernel_size < sizeof(struct setup_header) )
     {
-        xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
-                     "%s: kernel image too small", __FUNCTION__);
+        xc_dom_printf(dom->xch, "%s: kernel image too small", __FUNCTION__);
         return -EINVAL;
     }
 
@@ -584,8 +583,7 @@ static int xc_dom_probe_bzimage_kernel(s
 
     if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) != 0 )
     {
-        xc_dom_panic(dom->xch, XC_INVALID_KERNEL,
-                     "%s: kernel is not a bzImage", __FUNCTION__);
+        xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", __FUNCTION__);
         return -EINVAL;
     }

Re: Test result of xen-unstable changeset 25259

[Ian Campbell]

[...]
> Please try to see further in the xl create output on pv-grub test...
> ...
> libxl: debug: libxl_dm.c:987:libxl__create_device_model: Spawning
> device-model /usr/lib/xen/bin/qemu-system-i386 with arguments:
> libxl: debug: libxl_dm.c:989:libxl__create_device_model:  
> /usr/lib/xen/bin/qemu-system-i386
> ...
> Is it right?

It's not inherently wrong. A PV guest can end up with a qemu service
process to provide backends, like disk or VNC etc.

So the presence of a qemu does not necessarily imply an HVM guest.

Ian.

Re: Test result of xen-unstable changeset 25259

[Fantu]

Ian Campbell-10 wrote
> 
>> > About pv-grub I think it fails with:
>> > ... (from xl create...)
>> > xc: error: panic: xc_dom_bzimageloader.c:588:
>> xc_dom_probe_bzimage_kernel:
>> > kernel is not a bzImage: Invalid kernel
>> > ...
>> > And after seems start as hvm domU but is not working and I must destroy
>> it.
>> 
>> I think this is just a warning (which needs to be toned down), since the
>> pvgrub kernel isn't a bzImage, it's a simple elf file.
> 
> # HG changeset patch
> # User Ian Campbell <ian.campbell@>
> # Date 1336485612 -3600
> # Node ID 8aba3396a61a2224b7cb36046ce06bad053e956b
> # Parent  2fe12fc7bf1f863487920e06589641904b3d9466
> libxc: do not "panic" if a kernel is not a bzImage.
> 
> Up untul the point where we think this is a bzImage there is no point in
> printing panicy messages -- some other loader will have a go (probably the
> compressed ELF one)
> 
> Signed-off-by: Ian Campbell <ian.campbell@>
> 
> diff -r 2fe12fc7bf1f -r 8aba3396a61a tools/libxc/xc_dom_bzimageloader.c
> --- a/tools/libxc/xc_dom_bzimageloader.c	Tue May 08 14:25:27 2012 +0100
> +++ b/tools/libxc/xc_dom_bzimageloader.c	Tue May 08 15:00:12 2012 +0100
> @@ -575,8 +575,7 @@ static int xc_dom_probe_bzimage_kernel(s
>  
>      if ( dom->kernel_size < sizeof(struct setup_header) )
>      {
> -        xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
> -                     "%s: kernel image too small", __FUNCTION__);
> +        xc_dom_printf(dom->xch, "%s: kernel image too small",
> __FUNCTION__);
>          return -EINVAL;
>      }
>  
> @@ -584,8 +583,7 @@ static int xc_dom_probe_bzimage_kernel(s
>  
>      if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) != 0 )
>      {
> -        xc_dom_panic(dom->xch, XC_INVALID_KERNEL,
> -                     "%s: kernel is not a bzImage", __FUNCTION__);
> +        xc_dom_printf(dom->xch, "%s: kernel is not a bzImage",
> __FUNCTION__);
>          return -EINVAL;
>      }
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@.xen
> http://lists.xen.org/xen-devel
> 
I rebuilt with this patch and on fully clean install  on test server.

With pygrub same result.

With pv-grub:
Vnc seems not to work (black screen), possible regression with qemu-xen as
default for PV guest? Should I try to revert this
(http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a095e157f280) on next
build to make sure there aren't any bugs left on qemu-xen?
With xl console I get the pv-grub "recovery mode", possible regression about
disks?

-----------------------------------
xl -vvv create /etc/xenlucid.cfg
Parsing config file lucid.cfg
libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
vdev=xvda1 spec.backend=unknown
libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend
phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk
vdev=xvda1, using backend tap
libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
vdev=xvda2 spec.backend=unknown
libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend
phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk
vdev=xvda2, using backend tap
domainbuilder: detail: xc_dom_allocate: cmdline="(hd0,0)/grub/grub.cfg",
features="(null)"
domainbuilder: detail: xc_dom_kernel_file:
filename="/usr/lib/xen/boot/pv-grub-x86_64.gz"
domainbuilder: detail: xc_dom_malloc_filemap    : 978 kB
domainbuilder: detail: xc_dom_malloc            : 14274 kB
domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0xf4abe -> 0xdf08ce
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.2, caps xen-3.0-x86_64
xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader
... 
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... 
domainbuilder: detail: xc_dom_probe_bzimage_kernel: kernel is not a bzImage
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... 
domainbuilder: detail: loader probe OK
xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x99ef00
xc: detail: elf_parse_binary: memory: 0x0 -> 0x99ef00
xc: detail: elf_xen_parse: __xen_guest:
"GUEST_OS=Mini-OS,XEN_VER=xen-3.0,VIRT_BASE=0x0,ELF_PADDR_OFFSET=0x0,HYPERCALL_PAGE=0x2,LOADER=generic"
xc: detail: elf_xen_parse_guest_info: GUEST_OS="Mini-OS"
xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0"
xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x0"
xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x0"
xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x2"
xc: detail: elf_xen_parse_guest_info: LOADER="generic"
xc: detail: elf_xen_addr_calc_check: addresses:
xc: detail:     virt_base        = 0x0
xc: detail:     elf_paddr_offset = 0x0
xc: detail:     virt_offset      = 0x0
xc: detail:     virt_kstart      = 0x0
xc: detail:     virt_kend        = 0x99ef00
xc: detail:     virt_entry       = 0x0
xc: detail:     p2m_base         = 0xffffffffffffffff
domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64: 0x0 ->
0x99ef00
domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages, 4k
each
domainbuilder: detail: xc_dom_mem_init: 0x20000 pages
domainbuilder: detail: xc_dom_boot_mem_init: called
domainbuilder: detail: x86_compat: guest xen-3.0-x86_64, address size 64
domainbuilder: detail: xc_dom_malloc            : 1024 kB
domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail: xc_dom_alloc_segment:   kernel       : 0x0 ->
0x99f000  (pfn 0x0 + 0x99f pages)
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x0+0x99f at
0x7fcf39dc4000
xc: detail: elf_load_binary: phdr 0 at 0x0x7fcf39dc4000 -> 0x0x7fcf3a762f00
domainbuilder: detail: xc_dom_alloc_segment:   phys2mach    : 0x99f000 ->
0xa9f000  (pfn 0x99f + 0x100 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x99f+0x100 at
0x7fcf39cc4000
domainbuilder: detail: xc_dom_alloc_page   :   start info   : 0xa9f000 (pfn
0xa9f)
domainbuilder: detail: xc_dom_alloc_page   :   xenstore     : 0xaa0000 (pfn
0xaa0)
domainbuilder: detail: xc_dom_alloc_page   :   console      : 0xaa1000 (pfn
0xaa1)
domainbuilder: detail: nr_page_tables: 0x0000ffffffffffff/48:
0x0000000000000000 -> 0x0000ffffffffffff, 1 table(s)
domainbuilder: detail: nr_page_tables: 0x0000007fffffffff/39:
0x0000000000000000 -> 0x0000007fffffffff, 1 table(s)
domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30:
0x0000000000000000 -> 0x000000003fffffff, 1 table(s)
domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21:
0x0000000000000000 -> 0x0000000000bfffff, 6 table(s)
domainbuilder: detail: xc_dom_alloc_segment:   page tables  : 0xaa2000 ->
0xaab000  (pfn 0xaa2 + 0x9 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xaa2+0x9 at
0x7fcf39cbb000
domainbuilder: detail: xc_dom_alloc_page   :   boot stack   : 0xaab000 (pfn
0xaab)
domainbuilder: detail: xc_dom_build_image  : virt_alloc_end : 0xaac000
domainbuilder: detail: xc_dom_build_image  : virt_pgtab_end : 0xc00000
domainbuilder: detail: xc_dom_boot_image: called
domainbuilder: detail: arch_setup_bootearly: doing nothing
domainbuilder: detail: xc_dom_compat_check: supported guest type:
xen-3.0-x86_64 <= matches
domainbuilder: detail: xc_dom_compat_check: supported guest type:
xen-3.0-x86_32p
domainbuilder: detail: xc_dom_compat_check: supported guest type:
hvm-3.0-x86_32
domainbuilder: detail: xc_dom_compat_check: supported guest type:
hvm-3.0-x86_32p
domainbuilder: detail: xc_dom_compat_check: supported guest type:
hvm-3.0-x86_64
domainbuilder: detail: xc_dom_update_guest_p2m: dst 64bit, pages 0x20000
domainbuilder: detail: clear_page: pfn 0xaa1, mfn 0x41b9d0
domainbuilder: detail: clear_page: pfn 0xaa0, mfn 0x41b9d1
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xa9f+0x1 at
0x7fcf39cba000
domainbuilder: detail: start_info_x86_64: called
domainbuilder: detail: setup_hypercall_page: vaddr=0x2000 pfn=0x2
domainbuilder: detail: domain builder memory footprint
domainbuilder: detail:    allocated
domainbuilder: detail:       malloc             : 15364 kB
domainbuilder: detail:       anon mmap          : 0 bytes
domainbuilder: detail:    mapped
domainbuilder: detail:       file mmap          : 978 kB
domainbuilder: detail:       domU mmap          : 10916 kB
domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn
0xcedda
domainbuilder: detail: shared_info_x86_64: called
domainbuilder: detail: vcpu_x86_64: called
domainbuilder: detail: vcpu_x86_64: cr3: pfn 0xaa2 mfn 0x41b9cf
domainbuilder: detail: launch_vm: called, ctxt=0x7fffd27bcdf0
domainbuilder: detail: xc_dom_release: called
libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
vdev=xvda1 spec.backend=tap
libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
vdev=xvda2 spec.backend=tap
libxl: debug: libxl_dm.c:987:libxl__create_device_model: Spawning
device-model /usr/lib/xen/bin/qemu-system-i386 with arguments:
libxl: debug: libxl_dm.c:989:libxl__create_device_model:  
/usr/lib/xen/bin/qemu-system-i386
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -xen-domid
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   4
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -chardev
libxl: debug: libxl_dm.c:989:libxl__create_device_model:  
socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-4,server,nowait
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -mon
libxl: debug: libxl_dm.c:989:libxl__create_device_model:  
chardev=libxl-cmd,mode=control
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -xen-attach
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -name
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   lucid
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -vnc
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   0.0.0.0:0,to=99
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -k
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   it
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -M
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   xenpv
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -m
libxl: debug: libxl_dm.c:989:libxl__create_device_model:   513
libxl: debug: libxl_qmp.c:692:libxl__qmp_initialize: connected to
/var/run/xen/qmp-libxl-4
libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: qmp
libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command:
'{"execute":"qmp_capabilities","id":1}'
libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return
libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command:
'{"execute":"query-chardev","id":2}'
libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return
libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command:
'{"execute":"query-vnc","id":3}'
libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return
Daemon running with PID 2616
xc: debug: hypercall buffer: total allocations:154 total releases:154
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:149 misses:2 toobig:3
--------------------------
xl-lucid.log
-----------
libxl: debug: libxl_event.c:406:watchfd_callback: watch event:
epath=@releaseDomain token=3/0 wpath=@releaseDomain w=0x7002a8
libxl: debug: libxl.c:806:domain_death_xswatch_callback: [evg=0x6fbc90:4]
from domid=4 nentries=1 rc=1
libxl: debug: libxl.c:817:domain_death_xswatch_callback: [evg=0x6fbc90:4]  
got=domaininfos[0] got->domain=4
libxl: debug: libxl.c:844:domain_death_xswatch_callback:  exists
shutdown_reported=0 dominf.flags=ffff0020
libxl: debug: libxl.c:810:domain_death_xswatch_callback: [evg=0] all
reported
libxl: debug: libxl.c:874:domain_death_xswatch_callback: domain death search
done
-----------------------------------


--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153p5696877.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

Re: Test result of xen-unstable changeset 25259

[Ian Campbell]

On Wed, 2012-05-09 at 10:21 +0100, Fantu wrote:
> Ian Campbell-10 wrote
> >
> >> > About pv-grub I think it fails with:
> >> > ... (from xl create...)
> >> > xc: error: panic: xc_dom_bzimageloader.c:588:
> >> xc_dom_probe_bzimage_kernel:
> >> > kernel is not a bzImage: Invalid kernel
> >> > ...
> >> > And after seems start as hvm domU but is not working and I must destroy
> >> it.
> >>
> >> I think this is just a warning (which needs to be toned down), since the
> >> pvgrub kernel isn't a bzImage, it's a simple elf file.
> >
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@>
> > # Date 1336485612 -3600
> > # Node ID 8aba3396a61a2224b7cb36046ce06bad053e956b
> > # Parent  2fe12fc7bf1f863487920e06589641904b3d9466
> > libxc: do not "panic" if a kernel is not a bzImage.
> >
> > Up untul the point where we think this is a bzImage there is no point in
> > printing panicy messages -- some other loader will have a go (probably the
> > compressed ELF one)
> >
> > Signed-off-by: Ian Campbell <ian.campbell@>
> >
> > diff -r 2fe12fc7bf1f -r 8aba3396a61a tools/libxc/xc_dom_bzimageloader.c
> > --- a/tools/libxc/xc_dom_bzimageloader.c      Tue May 08 14:25:27 2012 +0100
> > +++ b/tools/libxc/xc_dom_bzimageloader.c      Tue May 08 15:00:12 2012 +0100
> > @@ -575,8 +575,7 @@ static int xc_dom_probe_bzimage_kernel(s
> >
> >      if ( dom->kernel_size < sizeof(struct setup_header) )
> >      {
> > -        xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
> > -                     "%s: kernel image too small", __FUNCTION__);
> > +        xc_dom_printf(dom->xch, "%s: kernel image too small",
> > __FUNCTION__);
> >          return -EINVAL;
> >      }
> >
> > @@ -584,8 +583,7 @@ static int xc_dom_probe_bzimage_kernel(s
> >
> >      if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) != 0 )
> >      {
> > -        xc_dom_panic(dom->xch, XC_INVALID_KERNEL,
> > -                     "%s: kernel is not a bzImage", __FUNCTION__);
> > +        xc_dom_printf(dom->xch, "%s: kernel is not a bzImage",
> > __FUNCTION__);
> >          return -EINVAL;
> >      }
> >
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@.xen
> > http://lists.xen.org/xen-devel
> >
> I rebuilt with this patch and on fully clean install  on test server.
> 
> With pygrub same result.

Can you bisect this please.

> With pv-grub:
> Vnc seems not to work (black screen), possible regression with qemu-xen as
> default for PV guest? Should I try to revert this
> (http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a095e157f280) on next
> build to make sure there aren't any bugs left on qemu-xen?

Yes please.

Also setting "device_model_version" to qemu-xen-traditional should have
the same overall effect as reverting.


> With xl console I get the pv-grub "recovery mode", possible regression about
> disks?
> 
> -----------------------------------
> xl -vvv create /etc/xenlucid.cfg
> Parsing config file lucid.cfg
> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
> vdev=xvda1 spec.backend=unknown
> libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend
> phy unsuitable as phys path not a block device
> libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk
> vdev=xvda1, using backend tap
> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
> vdev=xvda2 spec.backend=unknown
> libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend
> phy unsuitable as phys path not a block device
> libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk
> vdev=xvda2, using backend tap
> domainbuilder: detail: xc_dom_allocate: cmdline="(hd0,0)/grub/grub.cfg",
> features="(null)"
> domainbuilder: detail: xc_dom_kernel_file:
> filename="/usr/lib/xen/boot/pv-grub-x86_64.gz"
> domainbuilder: detail: xc_dom_malloc_filemap    : 978 kB
> domainbuilder: detail: xc_dom_malloc            : 14274 kB
> domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0xf4abe -> 0xdf08ce
> domainbuilder: detail: xc_dom_boot_xen_init: ver 4.2, caps xen-3.0-x86_64
> xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
> domainbuilder: detail: xc_dom_parse_image: called
> domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader
> ...
> domainbuilder: detail: loader probe failed
> domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ...
> domainbuilder: detail: xc_dom_probe_bzimage_kernel: kernel is not a bzImage
> domainbuilder: detail: loader probe failed
> domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ...
> domainbuilder: detail: loader probe OK
> xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x99ef00
> xc: detail: elf_parse_binary: memory: 0x0 -> 0x99ef00
> xc: detail: elf_xen_parse: __xen_guest:
> "GUEST_OS=Mini-OS,XEN_VER=xen-3.0,VIRT_BASE=0x0,ELF_PADDR_OFFSET=0x0,HYPERCALL_PAGE=0x2,LOADER=generic"
> xc: detail: elf_xen_parse_guest_info: GUEST_OS="Mini-OS"
> xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0"
> xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x0"
> xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x0"
> xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x2"
> xc: detail: elf_xen_parse_guest_info: LOADER="generic"
> xc: detail: elf_xen_addr_calc_check: addresses:
> xc: detail:     virt_base        = 0x0
> xc: detail:     elf_paddr_offset = 0x0
> xc: detail:     virt_offset      = 0x0
> xc: detail:     virt_kstart      = 0x0
> xc: detail:     virt_kend        = 0x99ef00
> xc: detail:     virt_entry       = 0x0
> xc: detail:     p2m_base         = 0xffffffffffffffff
> domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64: 0x0 ->
> 0x99ef00
> domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages, 4k
> each
> domainbuilder: detail: xc_dom_mem_init: 0x20000 pages
> domainbuilder: detail: xc_dom_boot_mem_init: called
> domainbuilder: detail: x86_compat: guest xen-3.0-x86_64, address size 64
> domainbuilder: detail: xc_dom_malloc            : 1024 kB
> domainbuilder: detail: xc_dom_build_image: called
> domainbuilder: detail: xc_dom_alloc_segment:   kernel       : 0x0 ->
> 0x99f000  (pfn 0x0 + 0x99f pages)
> domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x0+0x99f at
> 0x7fcf39dc4000
> xc: detail: elf_load_binary: phdr 0 at 0x0x7fcf39dc4000 -> 0x0x7fcf3a762f00
> domainbuilder: detail: xc_dom_alloc_segment:   phys2mach    : 0x99f000 ->
> 0xa9f000  (pfn 0x99f + 0x100 pages)
> domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x99f+0x100 at
> 0x7fcf39cc4000
> domainbuilder: detail: xc_dom_alloc_page   :   start info   : 0xa9f000 (pfn
> 0xa9f)
> domainbuilder: detail: xc_dom_alloc_page   :   xenstore     : 0xaa0000 (pfn
> 0xaa0)
> domainbuilder: detail: xc_dom_alloc_page   :   console      : 0xaa1000 (pfn
> 0xaa1)
> domainbuilder: detail: nr_page_tables: 0x0000ffffffffffff/48:
> 0x0000000000000000 -> 0x0000ffffffffffff, 1 table(s)
> domainbuilder: detail: nr_page_tables: 0x0000007fffffffff/39:
> 0x0000000000000000 -> 0x0000007fffffffff, 1 table(s)
> domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30:
> 0x0000000000000000 -> 0x000000003fffffff, 1 table(s)
> domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21:
> 0x0000000000000000 -> 0x0000000000bfffff, 6 table(s)
> domainbuilder: detail: xc_dom_alloc_segment:   page tables  : 0xaa2000 ->
> 0xaab000  (pfn 0xaa2 + 0x9 pages)
> domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xaa2+0x9 at
> 0x7fcf39cbb000
> domainbuilder: detail: xc_dom_alloc_page   :   boot stack   : 0xaab000 (pfn
> 0xaab)
> domainbuilder: detail: xc_dom_build_image  : virt_alloc_end : 0xaac000
> domainbuilder: detail: xc_dom_build_image  : virt_pgtab_end : 0xc00000
> domainbuilder: detail: xc_dom_boot_image: called
> domainbuilder: detail: arch_setup_bootearly: doing nothing
> domainbuilder: detail: xc_dom_compat_check: supported guest type:
> xen-3.0-x86_64 <= matches
> domainbuilder: detail: xc_dom_compat_check: supported guest type:
> xen-3.0-x86_32p
> domainbuilder: detail: xc_dom_compat_check: supported guest type:
> hvm-3.0-x86_32
> domainbuilder: detail: xc_dom_compat_check: supported guest type:
> hvm-3.0-x86_32p
> domainbuilder: detail: xc_dom_compat_check: supported guest type:
> hvm-3.0-x86_64
> domainbuilder: detail: xc_dom_update_guest_p2m: dst 64bit, pages 0x20000
> domainbuilder: detail: clear_page: pfn 0xaa1, mfn 0x41b9d0
> domainbuilder: detail: clear_page: pfn 0xaa0, mfn 0x41b9d1
> domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xa9f+0x1 at
> 0x7fcf39cba000
> domainbuilder: detail: start_info_x86_64: called
> domainbuilder: detail: setup_hypercall_page: vaddr=0x2000 pfn=0x2
> domainbuilder: detail: domain builder memory footprint
> domainbuilder: detail:    allocated
> domainbuilder: detail:       malloc             : 15364 kB
> domainbuilder: detail:       anon mmap          : 0 bytes
> domainbuilder: detail:    mapped
> domainbuilder: detail:       file mmap          : 978 kB
> domainbuilder: detail:       domU mmap          : 10916 kB
> domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn
> 0xcedda
> domainbuilder: detail: shared_info_x86_64: called
> domainbuilder: detail: vcpu_x86_64: called
> domainbuilder: detail: vcpu_x86_64: cr3: pfn 0xaa2 mfn 0x41b9cf
> domainbuilder: detail: launch_vm: called, ctxt=0x7fffd27bcdf0
> domainbuilder: detail: xc_dom_release: called
> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
> vdev=xvda1 spec.backend=tap
> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
> vdev=xvda2 spec.backend=tap
> libxl: debug: libxl_dm.c:987:libxl__create_device_model: Spawning
> device-model /usr/lib/xen/bin/qemu-system-i386 with arguments:
> libxl: debug: libxl_dm.c:989:libxl__create_device_model:
> /usr/lib/xen/bin/qemu-system-i386
> libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -xen-domid
> libxl: debug: libxl_dm.c:989:libxl__create_device_model:   4
> libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -chardev
> libxl: debug: libxl_dm.c:989:libxl__create_device_model:
> socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-4,server,nowait
> libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -mon
> libxl: debug: libxl_dm.c:989:libxl__create_device_model:
> chardev=libxl-cmd,mode=control
> libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -xen-attach
> libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -name
> libxl: debug: libxl_dm.c:989:libxl__create_device_model:   lucid
> libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -vnc
> libxl: debug: libxl_dm.c:989:libxl__create_device_model:   0.0.0.0:0,to=99
> libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -k
> libxl: debug: libxl_dm.c:989:libxl__create_device_model:   it
> libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -M
> libxl: debug: libxl_dm.c:989:libxl__create_device_model:   xenpv
> libxl: debug: libxl_dm.c:989:libxl__create_device_model:   -m
> libxl: debug: libxl_dm.c:989:libxl__create_device_model:   513
> libxl: debug: libxl_qmp.c:692:libxl__qmp_initialize: connected to
> /var/run/xen/qmp-libxl-4
> libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: qmp
> libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command:
> '{"execute":"qmp_capabilities","id":1}'
> libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return
> libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command:
> '{"execute":"query-chardev","id":2}'
> libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return
> libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command:
> '{"execute":"query-vnc","id":3}'
> libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return
> Daemon running with PID 2616
> xc: debug: hypercall buffer: total allocations:154 total releases:154
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
> xc: debug: hypercall buffer: cache current size:2
> xc: debug: hypercall buffer: cache hits:149 misses:2 toobig:3
> --------------------------
> xl-lucid.log
> -----------
> libxl: debug: libxl_event.c:406:watchfd_callback: watch event:
> epath=@releaseDomain token=3/0 wpath=@releaseDomain w=0x7002a8
> libxl: debug: libxl.c:806:domain_death_xswatch_callback: [evg=0x6fbc90:4]
> from domid=4 nentries=1 rc=1
> libxl: debug: libxl.c:817:domain_death_xswatch_callback: [evg=0x6fbc90:4]
> got=domaininfos[0] got->domain=4
> libxl: debug: libxl.c:844:domain_death_xswatch_callback:  exists
> shutdown_reported=0 dominf.flags=ffff0020
> libxl: debug: libxl.c:810:domain_death_xswatch_callback: [evg=0] all
> reported
> libxl: debug: libxl.c:874:domain_death_xswatch_callback: domain death search
> done
> -----------------------------------
> 
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153p5696877.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: Test result of xen-unstable changeset 25259

[Fantu]

Ian Campbell-10 wrote
> 
> On Wed, 2012-05-09 at 10:21 +0100, Fantu wrote:
>> Ian Campbell-10 wrote
>> >
>> >> > About pv-grub I think it fails with:
>> >> > ... (from xl create...)
>> >> > xc: error: panic: xc_dom_bzimageloader.c:588:
>> >> xc_dom_probe_bzimage_kernel:
>> >> > kernel is not a bzImage: Invalid kernel
>> >> > ...
>> >> > And after seems start as hvm domU but is not working and I must
>> destroy
>> >> it.
>> >>
>> >> I think this is just a warning (which needs to be toned down), since
>> the
>> >> pvgrub kernel isn't a bzImage, it's a simple elf file.
>> >
>> > # HG changeset patch
>> > # User Ian Campbell <ian.campbell@>
>> > # Date 1336485612 -3600
>> > # Node ID 8aba3396a61a2224b7cb36046ce06bad053e956b
>> > # Parent  2fe12fc7bf1f863487920e06589641904b3d9466
>> > libxc: do not "panic" if a kernel is not a bzImage.
>> >
>> > Up untul the point where we think this is a bzImage there is no point
>> in
>> > printing panicy messages -- some other loader will have a go (probably
>> the
>> > compressed ELF one)
>> >
>> > Signed-off-by: Ian Campbell <ian.campbell@>
>> >
>> > diff -r 2fe12fc7bf1f -r 8aba3396a61a tools/libxc/xc_dom_bzimageloader.c
>> > --- a/tools/libxc/xc_dom_bzimageloader.c      Tue May 08 14:25:27 2012
>> +0100
>> > +++ b/tools/libxc/xc_dom_bzimageloader.c      Tue May 08 15:00:12 2012
>> +0100
>> > @@ -575,8 +575,7 @@ static int xc_dom_probe_bzimage_kernel(s
>> >
>> >      if ( dom->kernel_size < sizeof(struct setup_header) )
>> >      {
>> > -        xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
>> > -                     "%s: kernel image too small", __FUNCTION__);
>> > +        xc_dom_printf(dom->xch, "%s: kernel image too small",
>> > __FUNCTION__);
>> >          return -EINVAL;
>> >      }
>> >
>> > @@ -584,8 +583,7 @@ static int xc_dom_probe_bzimage_kernel(s
>> >
>> >      if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) != 0 )
>> >      {
>> > -        xc_dom_panic(dom->xch, XC_INVALID_KERNEL,
>> > -                     "%s: kernel is not a bzImage", __FUNCTION__);
>> > +        xc_dom_printf(dom->xch, "%s: kernel is not a bzImage",
>> > __FUNCTION__);
>> >          return -EINVAL;
>> >      }
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Xen-devel mailing list
>> > Xen-devel@.xen
>> > http://lists.xen.org/xen-devel
>> >
>> I rebuilt with this patch and on fully clean install  on test server.
>> 
>> With pygrub same result.
> 
> Can you bisect this please.
> 
>> With pv-grub:
>> Vnc seems not to work (black screen), possible regression with qemu-xen
>> as
>> default for PV guest? Should I try to revert this
>> (http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a095e157f280) on
>> next
>> build to make sure there aren't any bugs left on qemu-xen?
> 
> Yes please.
> 
> Also setting "device_model_version" to qemu-xen-traditional should have
> the same overall effect as reverting.
> 
About bisect, I will do it.
About qemu devices on pv I tried device_model_version="qemu-xen-traditional"
but same problem on pygrub and pv-grub, it seems the problem is not about
qemu-xen.

--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153p5696949.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

Re: Test result of xen-unstable changeset 25259

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] Test result of xen-unstable changeset 25259"):
> 
> libxc: do not "panic" if a kernel is not a bzImage.
> 
> Up untul the point where we think this is a bzImage there is no point in
> printing panicy messages -- some other loader will have a go (probably the
> compressed ELF one)
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Looks plausible.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>