Re: [Xen-devel] ARM64: XEN Domu not booting with the qemu qcow AARCH64 Ubuntu 15.04 disk

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 3 Jun 2015, Sanjeev Pandita wrote:
> On Tue, Jun 2, 2015 at 7:55 PM, Stefano Stabellini 
> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>       On Tue, 2 Jun 2015, Sanjeev Pandita wrote:
>       > From: Stefan Bader [mailto:stefan.bader@xxxxxxxxxxxxx]
>       > Sent: Tuesday, June 02, 2015 1:52 PM
>       > To: Sanjeev Pandita; xen-devel@xxxxxxxxxxxxx
>       > Cc: Ian.Campbell@xxxxxxxxxx; Pranavkumar Sawargaonkar;
>       > stefano.stabellini@xxxxxxxxxxxxx
>       > Subject: Re: [Xen-devel] ARM64: XEN Domu not booting with the qemu 
> qcow
>       > AARCH64 Ubuntu 15.04 disk
>       >
>       > On 02.06.2015 09:40, Sanjeev Pandita wrote:
>       > > All,
>       > >
>       > > I am pretty new to xen . I am trying to boot DOMU with qemu qcow
>       > > AARCH64 Ubuntu 15.04 disk on Xen but I am getting the errors which
>       > > link to "/usr/local/lib/xen/bin/qemu-system-i386".
>       > > Since I am working on aarch64 system the
>       > > /usr/local/lib/xen/bin/qemu-system-i386 bin might not be present or
>       > > might not work as expected.
>       >
>       > Because I am lacking hardware and feedback, the arm64 packaging is a
>       > rather theoretical exercise. At least for armhf I thought 
> qemu-system-x86
>       > was a dependency. That binary should provide x86 emulation on arm64, 
> the
>       > same as one could install qemu for other arches on x86.
>       > Have you tried to install qemu-system-x86 manually?
>       >
>       > -Stefan
>       >
>       > >
>       > > Please let me know how to make the Qemu qcow image work on Xen.
>       > > Attached are the DomU boot log and config file.
>       > >
>       > > Thanks,
>       > > San
>       >
>       > Thanks for your inputs, I have installed the qemu-system-i386 but my 
> DomU
>       > booting is still crashing with following short logs. Am I missing 
> anything
>       > ?
>       >
>       > Kernel Crash logs:
>       >
>       > xenbus_probe_frontend: 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...1
>       > 
> 30s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75
>       > 
> s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s...15s.
>       > ..10s...5s...0s...
>       >
>       > xenbus_probe_frontend: Timeout connecting to device: device/vbd/51712
>       > (local state 3, remote state 2)
>       > console [netcon0] enabled
>       > netconsole: network logging started
>       > drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
>       > VFS: Cannot open root device "xvda" or unknown-block(0,0): error -6
>       > Please append a correct "root=" boot option; here are the available
>       > partitions:
>       > Kernel panic - not syncing: VFS: Unable to mount root fs on
>       > unknown-block(0,0)
>       > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.8 #5
>       > Hardware name: XENVM-4.6 (DT)
>       > Call trace:
>       > [<ffffffc00008a0dc>] dump_backtrace+0x0/0x124
>       > [<ffffffc00008a210>] show_stack+0x10/0x1c
>       > [<ffffffc000657d88>] dump_stack+0x80/0xc4
>       > [<ffffffc000656f04>] panic+0xe0/0x220
>       > [<ffffffc00087eea8>] mount_block_root+0x1a4/0x24c
>       > [<ffffffc00087f19c>] mount_root+0x110/0x130
>       > [<ffffffc00087f328>] prepare_namespace+0x16c/0x1b8
>       > [<ffffffc00087eb44>] kernel_init_freeable+0x1c4/0x1ec
>       > [<ffffffc00065481c>] kernel_init+0xc/0xd8
>       > ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on
>       > unknown-block(0,0)
> 
> It looks like the backend (QEMU) hasn't been initialized properly.
> Could you please post the output of xenstore-ls? Also could you run ps
> aux|grep qemu to check whether QEMU was spawned correctly?
> 
> 
> Attaching output of xenstore-ls and grep qemu.
> Looks like qemu process is getting spawned and running fine.
> 
> I have also modified the config file to remove tap from disk like:
> disk = [ 'qcow:/mnt/xen/vivid-server-cloudimg-arm64-disk1.img,xvda,w' ]
> But still my DOMU booting is stuck and getting crashed due to lack of 
> rootfs/disk.
> 
> I am running this on mustang board.

QEMU has been spawn correctly, and I can see that it changed the
backend state to "2" (/local/domain/0/backend/qdisk/1/51712 in xenstore).

Similarly the frontend initialization has started as the frontend state
has been changed to "3".

However they should be both "4". So unless you manage to capture a
transient state, the communication between frontend and backend got
stuck. I don't know why.

Is there anything interesting in the QEMU logs (under /var/log/xen) ?

If not, I think you might have to build your own QEMU and add some
tracing, something like this:


diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 21842a0..e62c14d 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -755,6 +755,9 @@ static void blk_alloc(struct XenDevice *xendev)
 {
     struct XenBlkDev *blkdev = container_of(xendev, struct XenBlkDev, xendev);
 
+
+    printf("DEBUG %s %d\n",__func__,__LINE__);
+
     QLIST_INIT(&blkdev->inflight);
     QLIST_INIT(&blkdev->finished);
     QLIST_INIT(&blkdev->freelist);
@@ -767,6 +770,9 @@ static void blk_alloc(struct XenDevice *xendev)
         xen_be_printf(xendev, 0, "xc_gnttab_set_max_grants failed: %s\n",
                       strerror(errno));
     }
+
+    printf("DEBUG %s %d\n",__func__,__LINE__);
+
 }
 
 static void blk_parse_discard(struct XenBlkDev *blkdev)
@@ -790,6 +796,7 @@ static int blk_init(struct XenDevice *xendev)
     int info = 0;
     char *directiosafe = NULL;
 
+    printf("DEBUG %s %d\n",__func__,__LINE__);
     /* read xenstore entries */
     if (blkdev->params == NULL) {
         char *h = NULL;
@@ -853,6 +860,8 @@ static int blk_init(struct XenDevice *xendev)
 
     blk_parse_discard(blkdev);
 
+    printf("DEBUG %s %d\n",__func__,__LINE__);
+
     g_free(directiosafe);
     return 0;
 
@@ -878,6 +887,8 @@ static int blk_connect(struct XenDevice *xendev)
     int pers, index, qflags;
     bool readonly = true;
 
+    printf("DEBUG %s %d\n",__func__,__LINE__);
+
     /* read-only ? */
     if (blkdev->directiosafe) {
         qflags = BDRV_O_NOCACHE | BDRV_O_NATIVE_AIO;
@@ -1026,6 +1037,9 @@ static int blk_connect(struct XenDevice *xendev)
                   "remote port %d, local port %d\n",
                   blkdev->xendev.protocol, blkdev->ring_ref,
                   blkdev->xendev.remote_port, blkdev->xendev.local_port);
+
+    printf("DEBUG %s %d\n",__func__,__LINE__);
+
     return 0;
 }
 
@@ -1033,6 +1047,9 @@ static void blk_disconnect(struct XenDevice *xendev)
 {
     struct XenBlkDev *blkdev = container_of(xendev, struct XenBlkDev, xendev);
 
+
+    printf("DEBUG %s %d\n",__func__,__LINE__);
+
     if (blkdev->blk) {
         blk_detach_dev(blkdev->blk, blkdev);
         blk_unref(blkdev->blk);
@@ -1083,6 +1100,9 @@ static int blk_free(struct XenDevice *xendev)
         g_free(ioreq);
     }
 
+
+    printf("DEBUG %s %d\n",__func__,__LINE__);
+
     g_free(blkdev->params);
     g_free(blkdev->mode);
     g_free(blkdev->type);

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel