Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

2017-08-09 Thread Roger Pau Monné 
On Tue, Aug 08, 2017 at 07:55:16PM +0300, Alexander Nusov wrote:
> Hello,
> 
> tried booting from qcow2 on FreeBSD 11.1-RELEASE, the issue still exists.

Hm, great. Now it's too late to fix 11.1 :(. Have you tried with HEAD?

Thanks, Roger.
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

2017-08-08 Thread Alexander Nusov 
Hello,

tried booting from qcow2 on FreeBSD 11.1-RELEASE, the issue still exists.



--

thanks,

alex




 On Mon, 27 Feb 2017 18:45:38 +0300 Alexander Nusov 
alexander.nu...@nfvexpress.com wrote 




Not yet,

I’ll try the HEAD this week.



—

alex





 On Feb 27, 2017, at 6:34 PM, Roger Pau Monné roger@citrix.com 
wrote:

 

 On Mon, Feb 27, 2017 at 06:30:12PM +0300, Alexander Nusov wrote:

 Hi, 

 Sorry for top posting.

 

 Any update on the issue?

 Please let me know if I need open a bug in Bugzilla.

 

 Sadly it seems like there are still some loose ends on the VM subsystem. I 
hope

 those will be fixed soon. Have you tried with HEAD recently?

 

 Roger.





___

freebsd-xen@freebsd.org mailing list

https://lists.freebsd.org/mailman/listinfo/freebsd-xen

To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"






___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

2017-02-27 Thread Alexander Nusov 
Not yet,
I’ll try the HEAD this week.

—
alex


> On Feb 27, 2017, at 6:34 PM, Roger Pau Monné  wrote:
> 
> On Mon, Feb 27, 2017 at 06:30:12PM +0300, Alexander Nusov wrote:
>> Hi, 
>> Sorry for top posting.
>> 
>> Any update on the issue?
>> Please let me know if I need open a bug in Bugzilla.
> 
> Sadly it seems like there are still some loose ends on the VM subsystem. I 
> hope
> those will be fixed soon. Have you tried with HEAD recently?
> 
> Roger.


___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

2017-02-27 Thread Roger Pau Monné 
On Mon, Feb 27, 2017 at 06:30:12PM +0300, Alexander Nusov wrote:
> Hi, 
> Sorry for top posting.
> 
> Any update on the issue?
> Please let me know if I need open a bug in Bugzilla.

Sadly it seems like there are still some loose ends on the VM subsystem. I hope
those will be fixed soon. Have you tried with HEAD recently?

Roger.
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

2017-02-13 Thread Alexander Nusov 
Hi!

Please notify me when the issue will be fixed so I could start backporting 
patches to 11.0 to test qcow backend.

 On Fri, 03 Feb 2017 13:14:02 +0300 roger@citrix.com wrote 

On Thu, Feb 02, 2017 at 11:37:02PM +, Akshay Jaggi wrote: 
> [-Alex] 
> 
> Hi Roger, 
> 
> Did this get solved with the change you submitted to Xen? 

This issue is cased by a bug in the VM subsystem, kib is currently looking into 
it, and patches will be committed soon hopefully. The Xen patch I've sent is 
the FreeBSD handlers for the gnttab lib, with that everything is already 
upstream :). I will backport the Xen patch to your Xen package once the VM 
issue is solved. 

Thanks, Roger. 
___ 
freebsd-xen@freebsd.org mailing list 
https://lists.freebsd.org/mailman/listinfo/freebsd-xen 
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org" 
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

2017-02-03 Thread Roger Pau Monné 
On Thu, Feb 02, 2017 at 11:37:02PM +, Akshay Jaggi wrote:
> [-Alex]
> 
> Hi Roger,
> 
> Did this get solved with the change you submitted to Xen?

This issue is cased by a bug in the VM subsystem, kib is currently looking into
it, and patches will be committed soon hopefully. The Xen patch I've sent is
the FreeBSD handlers for the gnttab lib, with that everything is already
upstream :). I will backport the Xen patch to your Xen package once the VM
issue is solved.

Thanks, Roger.
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

2017-02-02 Thread Akshay Jaggi 
[-Alex]

Hi Roger,

Did this get solved with the change you submitted to Xen?

On 25 January 2017 at 11:58, Alexander Nusov  wrote:

> Cool, many thanks!
>
> --
> Alex
>
>  On Wed, 25 Jan 2017 14:50:51 +0300 *Roger Pau Monné
> >* wrote 
>
> On Wed, Jan 25, 2017 at 02:20:55PM +0300, Alexander Nusov wrote:
> > Got it, thanks.
> >
> >
> >
> > I found a workaround to avoid XENBUS delay in Linux DomUs by adding
> xen_platform_pci = 0 to the configuration file.
> >
> > So FreeBSD 11.0 Dom0 can boot Linux guests and Windows Server (FreeBSD
> DomU still stuck on xenbusb_nop_confighook_cb) from QCOW2 images (also
> works with QCOW2 overlay images)
> >
>
> On FreeBSD you can boot with QCOW2 by not setting "xen_platform_pci = 0"
> on the
> guest config file and adding "hw.xen.disable_pv_disks=1" to the
> /boot/loader.conf file of the guest. This will prevent FreeBSD from using
> the
> PV disk, but you will still get the PV network interfaces.
>
> >
> > Can you tell me please what is the disadvantage of not using
> /dev/xen/vbd devices and drivers in guests? like slow I/O?
>
> Slow IO only.
>
> > May it lead to data corruption?
>
> No.
>
>
>
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

2017-01-25 Thread Alexander Nusov 
Cool, many thanks!



--

Alex


 On Wed, 25 Jan 2017 14:50:51 +0300 Roger Pau Monné 
roger@citrix.com wrote 




On Wed, Jan 25, 2017 at 02:20:55PM +0300, Alexander Nusov wrote: 

 Got it, thanks. 

 

 

 

 I found a workaround to avoid XENBUS delay in Linux DomUs by adding 
xen_platform_pci = 0 to the configuration file. 

 

 So FreeBSD 11.0 Dom0 can boot Linux guests and Windows Server (FreeBSD 
DomU still stuck on xenbusb_nop_confighook_cb) from QCOW2 images (also works 
with QCOW2 overlay images) 

 

 

On FreeBSD you can boot with QCOW2 by not setting "xen_platform_pci = 0" on the 

guest config file and adding "hw.xen.disable_pv_disks=1" to the 

/boot/loader.conf file of the guest. This will prevent FreeBSD from using the 

PV disk, but you will still get the PV network interfaces. 

 

 

 Can you tell me please what is the disadvantage of not using /dev/xen/vbd 
devices and drivers in guests? like slow I/O? 

 

Slow IO only. 

 

 May it lead to data corruption? 

 

No. 






___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

2017-01-25 Thread Roger Pau Monné 
On Wed, Jan 25, 2017 at 02:20:55PM +0300, Alexander Nusov wrote:
> Got it, thanks.
> 
> 
> 
> I found a workaround to avoid XENBUS delay in Linux DomUs by adding 
> xen_platform_pci = 0 to the configuration file.
> 
> So FreeBSD 11.0 Dom0 can boot Linux guests and Windows Server (FreeBSD DomU 
> still stuck on xenbusb_nop_confighook_cb) from QCOW2 images (also works with 
> QCOW2 overlay images)
> 

On FreeBSD you can boot with QCOW2 by not setting "xen_platform_pci = 0" on the
guest config file and adding "hw.xen.disable_pv_disks=1" to the
/boot/loader.conf file of the guest. This will prevent FreeBSD from using the
PV disk, but you will still get the PV network interfaces.

> 
> Can you tell me please what is the disadvantage of not using /dev/xen/vbd 
> devices and drivers in guests? like slow I/O? 

Slow IO only.

> May it lead to data corruption?

No.
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

2017-01-25 Thread Alexander Nusov 
Got it, thanks.



I found a workaround to avoid XENBUS delay in Linux DomUs by adding 
xen_platform_pci = 0 to the configuration file.

So FreeBSD 11.0 Dom0 can boot Linux guests and Windows Server (FreeBSD DomU 
still stuck on xenbusb_nop_confighook_cb) from QCOW2 images (also works with 
QCOW2 overlay images)



Can you tell me please what is the disadvantage of not using /dev/xen/vbd 
devices and drivers in guests? like slow I/O? 

May it lead to data corruption?


--

Alex




 On Wed, 25 Jan 2017 12:35:14 +0300 Akshay Jaggi ja...@freebsd.org 
wrote 




Hi Alex and Roger,



Without the patch and FreeBSD 12, qcow2 doesn't actually work. We were thinking 
of adding code to warn against this, but then thought gntdev implementation is 
in process anyway.

With the patch, the crash needs to be investigated (because I did run one of 
the gntdev based image, most probably qcow2, iirc).

Sadly, I'm still searching for housing in Dublin, and hence won't be able to 
look at this immediately. Two weeks, to find and then move in, if I'm lucky. 
Meanwhile, I'll start hunting for a development machine in office.



Regards,

Akshay






On Jan 24, 2017 16:56, Roger Pau Monné roger@citrix.com wrote:






On Tue, Jan 24, 2017 at 05:45:25PM +0300, Alexander Nusov wrote:

 Yes, it was FreeBSD 11.0-STABLE Dom0 with xen-kernel/xen-tools built from 
the ports tree (head)







 It seems there is an issue with xen pci devices, since booting from QCOW2 
images actually works (even on FreeBSD 11.0-RELEASE branch) except 
communication with /xen/vbd devices from the guest.



Yes, I'm seeing exactly the same. The QEMU process is killed with a

segmentation fault. Akshay, here is the full debug output:



Program terminated with signal 11, Segmentation fault.

[...]

#0  blk_handle_requests (blkdev=0x807463c00) at hw/block/xen_disk.c:862

862 rp = blkdev-rings.common.sring-req_prod;

[New Thread 8087f9000 (LWP 100947/unknown)]

[New Thread 807418800 (LWP 100945/unknown)]

[New Thread 807418300 (LWP 100944/unknown)]

[New Thread 807417e00 (LWP 100943/unknown)]

[New Thread 807417900 (LWP 100942/unknown)]

[New Thread 807417400 (LWP 100941/unknown)]

[New Thread 807416a00 (LWP 100940/unknown)]

[New Thread 807416500 (LWP 100939/unknown)]

[New Thread 807416000 (LWP 100091/unknown)]

(gdb) bt

#0  blk_handle_requests (blkdev=0x807463c00) at hw/block/xen_disk.c:862

#1  0x005f9dcd in blk_bh (opaque=0x807463c00) at hw/block/xen_disk.c:918

#2  0x0080ba69 in aio_bh_call (bh=0x80780d810) at async.c:87

#3  0x0080bb10 in aio_bh_poll (ctx=0x8074a0680) at async.c:115

#4  0x0081c099 in aio_dispatch (ctx=0x8074a0680) at aio-posix.c:303

#5  0x0080c2cd in aio_ctx_dispatch (source=0x8074a0680, callback=0, 
user_data=0x0)

at async.c:254

#6  0x000802e3903b in g_main_context_dispatch () from 
/usr/local/lib/libglib-2.0.so.0

#7  0x0081a34c in glib_pollfds_poll () at main-loop.c:259

#8  0x00819dc5 in os_host_main_loop_wait (timeout=0) at main-loop.c:306

#9  0x00819c29 in main_loop_wait (nonblocking=0) at main-loop.c:556

#10 0x00588ed7 in main_loop () at vl.c:1966

#11 0x00583b59 in main (argc=38, argv=0x7fffe750, 
envp=0x7fffe888) at vl.c:4684

Current language:  auto; currently minimal



It seems like the device is not properly mapping the grants, and QEMU gets a

SEGFAULT when trying to access the ring page.



Roger.





___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

2017-01-25 Thread Akshay Jaggi 
Hi Alex and Roger,

Without the patch and FreeBSD 12, qcow2 doesn't actually work. We were
thinking of adding code to warn against this, but then thought gntdev
implementation is in process anyway.
With the patch, the crash needs to be investigated (because I did run one
of the gntdev based image, most probably qcow2, iirc).
Sadly, I'm still searching for housing in Dublin, and hence won't be able
to look at this immediately. Two weeks, to find and then move in, if I'm
lucky. Meanwhile, I'll start hunting for a development machine in office.

Regards,
Akshay

On Jan 24, 2017 16:56, Roger Pau Monné  wrote:

> On Tue, Jan 24, 2017 at 05:45:25PM +0300, Alexander Nusov wrote:
> > Yes, it was FreeBSD 11.0-STABLE Dom0 with xen-kernel/xen-tools built
> from the ports tree (head)
> >
> >
> >
> > It seems there is an issue with xen pci devices, since booting from
> QCOW2 images actually works (even on FreeBSD 11.0-RELEASE branch) except
> communication with /xen/vbd devices from the guest.
>
> Yes, I'm seeing exactly the same. The QEMU process is killed with a
> segmentation fault. Akshay, here is the full debug output:
>
> Program terminated with signal 11, Segmentation fault.
> [...]
> #0  blk_handle_requests (blkdev=0x807463c00) at hw/block/xen_disk.c:862
> 862 rp = blkdev->rings.common.sring->req_prod;
> [New Thread 8087f9000 (LWP 100947/)]
> [New Thread 807418800 (LWP 100945/)]
> [New Thread 807418300 (LWP 100944/)]
> [New Thread 807417e00 (LWP 100943/)]
> [New Thread 807417900 (LWP 100942/)]
> [New Thread 807417400 (LWP 100941/)]
> [New Thread 807416a00 (LWP 100940/)]
> [New Thread 807416500 (LWP 100939/)]
> [New Thread 807416000 (LWP 100091/)]
> (gdb) bt
> #0  blk_handle_requests (blkdev=0x807463c00) at hw/block/xen_disk.c:862
> #1  0x005f9dcd in blk_bh (opaque=0x807463c00) at
> hw/block/xen_disk.c:918
> #2  0x0080ba69 in aio_bh_call (bh=0x80780d810) at async.c:87
> #3  0x0080bb10 in aio_bh_poll (ctx=0x8074a0680) at async.c:115
> #4  0x0081c099 in aio_dispatch (ctx=0x8074a0680) at aio-posix.c:303
> #5  0x0080c2cd in aio_ctx_dispatch (source=0x8074a0680,
> callback=0, user_data=0x0)
> at async.c:254
> #6  0x000802e3903b in g_main_context_dispatch () from /usr/local/lib/
> libglib-2.0.so.0
> #7  0x0081a34c in glib_pollfds_poll () at main-loop.c:259
> #8  0x00819dc5 in os_host_main_loop_wait (timeout=0) at
> main-loop.c:306
> #9  0x00819c29 in main_loop_wait (nonblocking=0) at main-loop.c:556
> #10 0x00588ed7 in main_loop () at vl.c:1966
> #11 0x00583b59 in main (argc=38, argv=0x7fffe750,
> envp=0x7fffe888) at vl.c:4684
> Current language:  auto; currently minimal
>
> It seems like the device is not properly mapping the grants, and QEMU gets
> a
> SEGFAULT when trying to access the ring page.
>
> Roger.
>
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

2017-01-24 Thread Roger Pau Monné 
On Tue, Jan 24, 2017 at 05:45:25PM +0300, Alexander Nusov wrote:
> Yes, it was FreeBSD 11.0-STABLE Dom0 with xen-kernel/xen-tools built from the 
> ports tree (head)
> 
> 
> 
> It seems there is an issue with xen pci devices, since booting from QCOW2 
> images actually works (even on FreeBSD 11.0-RELEASE branch) except 
> communication with /xen/vbd devices from the guest.

Yes, I'm seeing exactly the same. The QEMU process is killed with a
segmentation fault. Akshay, here is the full debug output:

Program terminated with signal 11, Segmentation fault.
[...]
#0  blk_handle_requests (blkdev=0x807463c00) at hw/block/xen_disk.c:862
862 rp = blkdev->rings.common.sring->req_prod;
[New Thread 8087f9000 (LWP 100947/)]
[New Thread 807418800 (LWP 100945/)]
[New Thread 807418300 (LWP 100944/)]
[New Thread 807417e00 (LWP 100943/)]
[New Thread 807417900 (LWP 100942/)]
[New Thread 807417400 (LWP 100941/)]
[New Thread 807416a00 (LWP 100940/)]
[New Thread 807416500 (LWP 100939/)]
[New Thread 807416000 (LWP 100091/)]
(gdb) bt
#0  blk_handle_requests (blkdev=0x807463c00) at hw/block/xen_disk.c:862
#1  0x005f9dcd in blk_bh (opaque=0x807463c00) at hw/block/xen_disk.c:918
#2  0x0080ba69 in aio_bh_call (bh=0x80780d810) at async.c:87
#3  0x0080bb10 in aio_bh_poll (ctx=0x8074a0680) at async.c:115
#4  0x0081c099 in aio_dispatch (ctx=0x8074a0680) at aio-posix.c:303
#5  0x0080c2cd in aio_ctx_dispatch (source=0x8074a0680, callback=0, 
user_data=0x0)
at async.c:254
#6  0x000802e3903b in g_main_context_dispatch () from 
/usr/local/lib/libglib-2.0.so.0
#7  0x0081a34c in glib_pollfds_poll () at main-loop.c:259
#8  0x00819dc5 in os_host_main_loop_wait (timeout=0) at main-loop.c:306
#9  0x00819c29 in main_loop_wait (nonblocking=0) at main-loop.c:556
#10 0x00588ed7 in main_loop () at vl.c:1966
#11 0x00583b59 in main (argc=38, argv=0x7fffe750, 
envp=0x7fffe888) at vl.c:4684
Current language:  auto; currently minimal

It seems like the device is not properly mapping the grants, and QEMU gets a
SEGFAULT when trying to access the ring page.

Roger.
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

2017-01-24 Thread Alexander Nusov 
Yes, it was FreeBSD 11.0-STABLE Dom0 with xen-kernel/xen-tools built from the 
ports tree (head)



It seems there is an issue with xen pci devices, since booting from QCOW2 
images actually works (even on FreeBSD 11.0-RELEASE branch) except 
communication with /xen/vbd devices from the guest.


By the way, I installed FreeBSD 12-CURRENT r311461 snapshot and applied the 
patch for xen-utils and now things got worse,

qemu-system-i386 process started to crash at this point:

[1.162342] GHES: HEST is not enabled!

[1.166829] xen-platform-pci :00:02.0: PCI INT A - GSI 24 (level, 
low) - IRQ 24

[1.191301] Grant table initialized

[1.197758] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled

[1.238473] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

[1.246103] init_memory_mapping: 2000-2800

[1.374895] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

[1.381290] Linux agpgart interface v0.103

[1.387732] brd: module loaded

[1.392518] loop: module loaded

CRASH



root@current:~ # cat /var/log/xen/xl-vm.log 

Waiting for domain vm (domid 4) to die [pid 18070]

libxl: debug: libxl_event.c:636:libxl__ev_xswatch_register: watch w=0x80321c3e0 
wpath=@releaseDomain token=3/0: register slotnum=3

libxl: debug: libxl_event.c:573:watchfd_callback: watch w=0x80321c3e0 
wpath=@releaseDomain token=3/0: event epath=@releaseDomain

libxl: debug: libxl.c:1184:domain_death_xswatch_callback: [evg=0x803221aa0:4] 
nentries=1 rc=1 4..4

libxl: debug: libxl.c:1195:domain_death_xswatch_callback: [evg=0x803221aa0:4]   
got=domaininfos[0] got-domain=4

libxl: debug: libxl.c:1221:domain_death_xswatch_callback:  exists 
shutdown_reported=0 dominf.flags=0002

libxl: debug: libxl.c:1188:domain_death_xswatch_callback: [evg=0] all reported

libxl: debug: libxl.c:1250:domain_death_xswatch_callback: domain death search 
done



Then I did a xen-utils rollback and stuck with the same issue (Waiting for 
XENBUS), no crash though.



root@current:~ # cat vm.cfg 

builder = "hvm" 

memory = 512 

vcpus = 2 

name = "vm" 

disk = 
['format=qcow2,vdev=xvda,access=rw,backendtype=qdisk,target=/root/cirros-0.3.4-x86_64-disk.img']

boot = "c" 

vnc = 1 

vnclisten = "0.0.0.0" 

usbdevice = 'tablet' 

on_poweroff = 'destroy' 

on_reboot = 'restart' 

on_crash = 'restart' 

acpi = 1 

serial = 'pty'



root@current:~ # cat /boot/loader.conf 

hw.pci.mcfg=0

xen_kernel="/boot/xen"

xen_cmdline="dom0_mem=8192M dom0_max_vcpus=8 dom0pvh=1 com1=115200,8n1 
guest_loglvl=all loglvl=all"



root@current:~ # cat /etc/sysctl.conf 

vm.max_wired=-1



root@current:~ # xl -vvv create vm.cfg

Parsing config from vm.cfg

libxl: debug: libxl_create.c:1710:do_domain_create: ao 0x803247000: create: 
how=0x0 callback=0x0 poller=0x8032280a0

libxl: debug: libxl_device.c:347:libxl__device_disk_set_backend: Disk vdev=xvda 
spec.backend=qdisk

libxl: debug: libxl_create.c:970:initiate_domain_create: running bootloader

libxl: debug: libxl_bootloader.c:324:libxl__bootloader_run: not a PV domain, 
skipping bootloader

libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch 
w=0x80325dab8: deregister unregistered

domainbuilder: detail: xc_dom_allocate: cmdline="(null)", features="(null)"

domainbuilder: detail: xc_dom_kernel_file: 
filename="/usr/local/lib/xen/boot/hvmloader"

domainbuilder: detail: xc_dom_malloc_filemap: 329 kB

domainbuilder: detail: xc_dom_boot_xen_init: ver 4.7, 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 ELF-generic 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 HVM-generic loader ... 

domainbuilder: detail: loader probe OK

xc: detail: elf_parse_binary: phdr: paddr=0x10 memsz=0x5ad0c

xc: detail: elf_parse_binary: memory: 0x10 - 0x15ad0c

domainbuilder: detail: xc_dom_mem_init: mem 504 MB, pages 0x1f800 pages, 4k each

domainbuilder: detail: xc_dom_mem_init: 0x1f800 pages

domainbuilder: detail: xc_dom_boot_mem_init: called

domainbuilder: detail: xc_dom_malloc: 1008 kB

xc: detail: PHYSICAL MEMORY ALLOCATION:

xc: detail:   4KB PAGES: 0x0200

xc: detail:   2MB PAGES: 0x00fb

xc: detail:   1GB PAGES: 0x

domainbuilder: detail: xc_dom_build_image: called

domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x100+0x5b 
at 0x8006d1000

domainbuilder: detail: xc_dom_alloc_segment:   kernel   : 0x10 - 
0x15b000  (pfn 0x100 + 0x5b pages)

xc: detail: elf_load_binary: phdr 0 at 0x80072c000 - 0x80077d2a8

domainbuilder: detail: alloc_pgtables_hvm: doing nothing

domainbuilder: detail:

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

2017-01-24 Thread Roger Pau Monné 
On Mon, Jan 23, 2017 at 06:25:23PM +0300, Alexander Nusov wrote:
> Hello,
> Sorry for cross-posting, since it's related to Xen hypervisor I'm forwarding 
> this message to the freebsd-xen mailing list.
> 
> I'm trying to launch a HVM DomU guest from QCOW2 image by using PV driver on 
> FreeBSD 11 Dom0.
> The issue is that guest cannot connect to the device/vbd and requires to wait 
> for 4 minutes to proceed, it goes through the countdown and starts fine 
> (disk, networking)
> 
> [6.684115] XENBUS: Waiting for devices to initialise: 
> 25s...20s...15s...10s...5s...0s...235s...230s...225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s...15s...10s...5s...0s...
> [  271.591403] XENBUS: Timeout connecting to device: device/vbd/51712 (local 
> state 3, remote state 1)
> [  271.599963] XENBUS: Device with no driver: device/vkbd/0
> [  271.604249]   Magic number: 1:453:334
> ...
> login: 
> 
> 
> Unlike Linux It's impossible to boot FreeBSD 11 guests from QCOW2 
> (xenbusb_nop_confighook_cb timeout)
> 
> Steps to reproduce:
> 1. Download qcow2 cirros image (small linux) 
> http://secure-web.cisco.com/1RtWXk7FS6UyRxe5A9ejZVfU2VK9512Yeds80mlP_0LoLwQJLjbPBoILL2e4QyF2OaMyO8fbrQrYVmfOybSYvHgWH1sRz1gK4Zi5XDAzBDUluwhlU4NxVQ7S17tH6vSTrIJmBJ_NO-sdA1Ph_KfSOsNvMkw-swwuKHD9ophVFfqEe6Lnt_PIP4H-LhZfp-5_aCuqbPYciXtMyxWbF1Od65jiFe-_LfmPRt53aCscOk7cBRI_-o603sb7htpDHH06Y8-M4oG5Lt4s1jr1XcKTrIWhnD-Lhz55blWyc2FnCgvk/http%3A%2F%2Fdownload.cirros-cloud.net%2F0.3.4%2Fcirros-0.3.4-x86_64-disk.img
>  
> 
>  
> >
> # file cirros-0.3.4-x86_64-disk.img 
> cirros-0.3.4-x86_64-disk.img: QEMU QCOW Image (v2), 41126400 bytes
> 2. create DomU from config bellow xl create -c config.cfg
> 
> builder = "hvm"
> memory = 512
> vcpus = 2
> name = "cirros"
> disk = [ 'file:qcow2:/root/cirros-0.3.4-x86_64-disk.img,xvda,w' ]
> boot = "c" 
> vnc = 1
> vnclisten = "0.0.0.0"
> usbdevice = 'tablet'
> on_poweroff = 'destroy'
> on_reboot = 'restart'
> on_crash = 'restart'
> acpi = 1
> serial = 'pty'
> 
> I've also tried multiple configurations like tap:qcow2:. tap2:qcow2:, aio:, 
> switching from xen bus to ide. didn't work.
> The only driver that had no issues was PHY but it supports only RAW images.
> 
> Is that a bug or I'm missing something?
> 
> tested both STABLE snapshot and 11.0-RELEASE
> 
> # uname -a
> FreeBSD xen 11.0-STABLE FreeBSD 11.0-STABLE #0 r311441: Thu Jan  5 22:45:20 
> UTC 2017
> 
> # pkg info | grep xen
> xen-4.7.0_2Xen Hypervisor meta port
> xen-kernel-4.7.1_3 Hypervisor using a microkernel design
> xen-tools-4.7.1_1  Xen management tool, based on LibXenlight

So just that I understand this correctly, this is a FreeBSD 11.0-STABLE Dom0,
plus the Xen packages from pkg?

If that's the case, it's not going to work, FreeBSD 11.0 Dom0 doesn't yet
support qcow image format for HVM/PV guests, you will have to use FreeBSD 12
(HEAD) as your Dom0, or backport r308128 into STABLE (should be self contained,
so I don't expect any conflicts). You will also have to apply the following
patch to the xen-tools package and recompile:

https://lists.freebsd.org/pipermail/freebsd-xen/2016-August/002819.html

IIRC the right syntax to specify the disk device is:

'format=qcow2,vdev=xvda,access=rw,backendtype=qdisk,target=/root/cirros-0.3.4-x86_64-disk.img'

I'm also adding Akshay to the conversation, who did the gntdev implementation.

Roger.
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To

Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

2017-01-23 Thread Alexander Nusov 
Hello,
Sorry for cross-posting, since it's related to Xen hypervisor I'm forwarding 
this message to the freebsd-xen mailing list.

I'm trying to launch a HVM DomU guest from QCOW2 image by using PV driver on 
FreeBSD 11 Dom0.
The issue is that guest cannot connect to the device/vbd and requires to wait 
for 4 minutes to proceed, it goes through the countdown and starts fine (disk, 
networking)

[6.684115] XENBUS: Waiting for devices to initialise: 
25s...20s...15s...10s...5s...0s...235s...230s...225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s...15s...10s...5s...0s...
[  271.591403] XENBUS: Timeout connecting to device: device/vbd/51712 (local 
state 3, remote state 1)
[  271.599963] XENBUS: Device with no driver: device/vkbd/0
[  271.604249]   Magic number: 1:453:334
...
login: 


Unlike Linux It's impossible to boot FreeBSD 11 guests from QCOW2 
(xenbusb_nop_confighook_cb timeout)

Steps to reproduce:
1. Download qcow2 cirros image (small linux) 
http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img 
 
>
# file cirros-0.3.4-x86_64-disk.img 
cirros-0.3.4-x86_64-disk.img: QEMU QCOW Image (v2), 41126400 bytes
2. create DomU from config bellow xl create -c config.cfg

builder = "hvm"
memory = 512
vcpus = 2
name = "cirros"
disk = [ 'file:qcow2:/root/cirros-0.3.4-x86_64-disk.img,xvda,w' ]
boot = "c" 
vnc = 1
vnclisten = "0.0.0.0"
usbdevice = 'tablet'
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
acpi = 1
serial = 'pty'

I've also tried multiple configurations like tap:qcow2:. tap2:qcow2:, aio:, 
switching from xen bus to ide. didn't work.
The only driver that had no issues was PHY but it supports only RAW images.

Is that a bug or I'm missing something?

tested both STABLE snapshot and 11.0-RELEASE

# uname -a
FreeBSD xen 11.0-STABLE FreeBSD 11.0-STABLE #0 r311441: Thu Jan  5 22:45:20 UTC 
2017

# pkg info | grep xen
xen-4.7.0_2Xen Hypervisor meta port
xen-kernel-4.7.1_3 Hypervisor using a microkernel design
xen-tools-4.7.1_1  Xen management tool, based on LibXenlight

# cat /boot/loader.conf 
hw.pci.mcfg=0
xen_kernel="/boot/xen"
xen_cmdline="dom0_mem=8192M dom0_max_vcpus=8 dom0pvh=1 com1=115200,8n1 
guest_loglvl=all loglvl=all"

# xenstore-ls -p
 4 = "" . . . . . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
  vm = "/vm/94b147df-e15d-11e6-a685-002590d7eca6" . . . . .  (n0,r4)
  name = "cirros" . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
  cpu = ""  . . . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
   0 = "" . . . . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
availability = "online" . . . . . . . . . . . . . . . .  (n0,r4)
   1 = "" . . . . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
availability = "online" . . . . . . . . . . . . . . . .  (n0,r4)
  memory = "" . . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
   static-max = "4194304" . . . . . . . . . . . . . . . . .  (n0,r4)
   target = "4186112" . . . . . . . . . . . . . . . . . . .  (n0,r4)
   videoram = "8192"  . . . . . . . . . . . . . . . . . . .  (n0,r4)
  device = "" . . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
   suspend = "" . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
event-channel = ""  . . . . . . . . . . . . . . . . . .  (n4)
   vbd = "" . . . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
51712 = ""  . . . . . . . . . . . . . . . . . . . . . .  (n4,r0)
 backend = "/local/domain/0/backend/qdisk/4/51712"  . .  (n4,r0)
 backend-id = "0" . . . . . . . . . . . . . . . . . . .  (n4,r0)
 state = "3"  . . . . . . . . . . . . . . . . . . . . .  (n4,r0)
 virtual-device = "51712" . . . . . . . . . . . . . . .  (n4,r0)
 device-type = "disk" . . . . . . . . . . . . . . . . .  (n4,r0)
 ring-ref = "8" . . . . . . . . . . . . . . . . . . . .  (n4,r0)
 event-channel = "18" . . . . . . . . . . . . . . . . .  (n4,r0)
 protocol = "x86_64-abi"  . . . . . . . . . . . . . . .  (n4,r0)
   vkbd = ""  . . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
0 = ""  . . . . . . . . . . . . . . . . . . . . . . . .  (n4,r0)
 backend = "/local/domain/0/backend/vkbd/4/0" . . . . .  (n4,r0)
 backend-id = "0" . . . . . . . . . . . . . . . . . . .  (n4,r0)
 state = "1"  . . . . . . . . . . . . . . . . . . . . .  (n4,r0)
  control = ""  . . . . . . . . . . . . . . . . . . . . . .  (n0,r4)
   shutdown = ""  . . . . . . . . . . . . . . . . . . . . .  (n4)
   platform-feature-multiprocessor-suspend = "1"  . . . . .  (n0,r4)