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

[Sanjeev Pandita <spandita@xxxxxxx>]

Hi Stefano,

On Wed, Jun 3, 2015 at 3:45 PM, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> wrote:

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

I checked /var/log/xen. Here is the error message.

linux:/var/log/xen # cat qemu-dm-vm4.log
xen be: qdisk-51712: error: 'xvda' uses a qcow feature which is not supported by this qemu version: QCOW version 2
xen be: qdisk-51712: initialise() failed

Thanks,

San

 

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

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, 
is for the sole use of the intended recipient(s) and contains information
that is confidential and proprietary to Applied Micro Circuits Corporation or its subsidiaries. 
It is to be used solely for the purpose of furthering the parties' business relationship. 
All unauthorized review, use, disclosure or distribution is prohibited. 
If you are not the intended recipient, please contact the sender by reply e-mail 
and destroy all copies of the original message.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel