From mirageos-devel-bounces@lists.xenproject.org Sun Nov 01 14:06:50 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 01 Nov 2020 14:06:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.17222.42030 (Exim 4.92) (envelope-from ) id 1kZE06-0004I2-JP; Sun, 01 Nov 2020 14:06:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 17222.42030; Sun, 01 Nov 2020 14:06:30 +0000 X-BeenThere: mirageos-devel@lists.xenproject.org List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mirageos-devel-bounces@lists.xenproject.org Precedence: list Sender: "MirageOS-devel" Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kZE06-0004Hv-FS; Sun, 01 Nov 2020 14:06:30 +0000 Received: by outflank-mailman (input) for mailman id 17222; Sun, 01 Nov 2020 14:06:28 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kZE04-0004Hq-Dr for mirageos-devel@lists.xenproject.org; Sun, 01 Nov 2020 14:06:28 +0000 Received: from mail-ed1-x531.google.com (unknown [2a00:1450:4864:20::531]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bf529b8c-3858-4ffb-a6ca-252809577af0; Sun, 01 Nov 2020 14:06:26 +0000 (UTC) Received: by mail-ed1-x531.google.com with SMTP id l24so11456919edj.8 for ; Sun, 01 Nov 2020 06:06:26 -0800 (PST) Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kZE04-0004Hq-Dr for mirageos-devel@lists.xenproject.org; Sun, 01 Nov 2020 14:06:28 +0000 X-Inumbo-ID: bf529b8c-3858-4ffb-a6ca-252809577af0 Received: from mail-ed1-x531.google.com (unknown [2a00:1450:4864:20::531]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bf529b8c-3858-4ffb-a6ca-252809577af0; Sun, 01 Nov 2020 14:06:26 +0000 (UTC) Received: by mail-ed1-x531.google.com with SMTP id l24so11456919edj.8 for ; Sun, 01 Nov 2020 06:06:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MuYBBdIwFcia0WqTL6o6VSlIAkqkuBqFQVBW7b41UFo=; b=GZAVaSCqgwmiyHqywwQ79yGtEMB9hewbxsgvAuwQYBroN8HA+aicK9IoB84hy8Aq5N U7YOf23IUNdE3txqszYE4wSGu+sYmkGXaJ2yIsRo45skHB6Q1Xy0uwQfLcSWbTRPenOz 0S1Lr7cu/r9y8VSBtLHUKJqJCw5Ujir5oD+dwwV6XvRA9PlkOQkwBnB/gZAG4y49RAu4 yBi/LrI+o06VhELs82dLlRUYZkp5yI46PklTkzPZrt26brK+N9vCfKAwz/32mSBq4Mtf TZ/OpwVr5WR8Ig8Kfcqq4ohrwaFSeHUR8UJUoWoTMa7Hxbx0/XmDPhv93OTHvPKkveT9 rLLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MuYBBdIwFcia0WqTL6o6VSlIAkqkuBqFQVBW7b41UFo=; b=j6+opq2nub+uylKrhKSBr6BsVMtnU7m+/+B0mJLIvAM/MXl1E7cbNTJJyjqTchm7BK TLWWLzZf+TVGAmLgo8AF7ZSbH26PSNYOtVVMnmdi0DFWw49nc/Dws1yE3WcOkgWDA1uX 2hJ0uAds1+1RZWJ8BiEPeAjZspX9tFNWfXz/hfki2dJReOIOF+rPqmttQcRx/+Z5RlyG DrkHnuX/DDpLNthdDyIPz5zl4Jx+OfgcDN5FU/UVkTD+UPrEcS+rtJmE8pU4oQF2b7IL W2k6XIfsVZ03zrEw2qqr23lecxT0e0o1HVdGeD0CPQBKXHHu4ZrG2J7laOqMrtEancRT HdOQ== X-Gm-Message-State: AOAM530ZpFftqbkPLiO6V9nvHcPvVEn76bIKOpo19xf3QJoF6p0p0KNd LEKtCOt7sjCwznSxcp1BDufNLa3JagI71yRCvUQ= X-Google-Smtp-Source: ABdhPJySyCt7jiF3wCYlwd0dQa0mbaHWbJmllWQd54uUULN9qRxbAZOpphnv46n8QM1eR52660xydA8LOvY4Tz5noNk= X-Received: by 2002:a50:9ec6:: with SMTP id a64mr11863310edf.382.1604239585624; Sun, 01 Nov 2020 06:06:25 -0800 (PST) MIME-Version: 1.0 References: <20201016121547.GA19073@nodbug.lucina.net> <20201026103746.GB11343@nodbug.lucina.net> <20201026104335.GC11343@nodbug.lucina.net> In-Reply-To: From: Hans Ole Rafaelsen Date: Sun, 1 Nov 2020 15:06:14 +0100 Message-ID: Subject: Re: MirageOS on OpenStack problem To: Ricardo Koller Cc: Martin Lucina , mirageos-devel@lists.xenproject.org, Ricardo Koller Content-Type: multipart/alternative; boundary="000000000000a2c77e05b30c2220" --000000000000a2c77e05b30c2220 Content-Type: text/plain; charset="UTF-8" Hi Ricardo, Thanks for the patch. Now the image works at the OpenStack cloud I'm using. Regards, Hans Ole On Fri, Oct 30, 2020 at 8:55 PM Ricardo Koller wrote: > Hello, > > Was able to reproduce it and now have a better idea of what's going on > (with a temporary fix included). The issue happens when using qemu with a > boot disk image exposed as a virtio-blk device. The problem is that solo5 > tries to configure a virtio device that was already initialized/configured > at VM early boot time. Qemu gets "confused" with the second configuration > attempt, throws the "virtio: zero sized buffers are not allowed" error and > gets stuck (somewhere that I couldn't determine). > > Just in case, these are all the tests I tried (using qemu v3 as v5 has an > issue https://github.com/Solo5/solo5/issues/463). To make things simpler > I've been using the solo5 tests/test-net unikernel (c code, not mirage). > You can create disk-net.img in solo5 using: > tests (master) [83]> ../scripts/virtio-mkimage/solo5-virtio-mkimage.sh -f > raw disk-net.img test_net/test_net.virtio > > These work: > + boot disk image as an IDE device: > qemu-3 -drive file=disk-net.img,if=ide,format=raw -cpu Westmere -m 128 > -nodefaults -no-acpi -display none \ > -serial stdio -device virtio- net,netdev=n0 -netdev > tap,id=n0,ifname=tap100,script=no,downscript=no -device isa-debug-exit > > +boot disk image as a virtio-scsi device (same as google cloud): > qemu-3 -device virtio-scsi-pci,id=scsi \ > -device scsi-hd,drive=hd \ > -drive if=none,id=hd,file=disk-net.img,format=raw \ > -cpu Westmere -m 128 -nodefaults -no-acpi -display none -serial stdio \ > -device virtio-net,netdev=n0 -netdev > tap,id=n0,ifname=tap100,script=no,downscript=no -device isa-debug-exit > > These do NOT work: > + boot disk image as a virtio-blk device: > qemu-3 -drive file=disk-net.img,if=virtio,format=raw -cpu Westmere -m 128 > -nodefaults -no-acpi -display none \ > -serial stdio -device virtio-net,netdev=n0 -netdev > tap,id=n0,ifname=tap100,script=no,downscript=no -device isa-debug-exit > > The right fix would be to check in solo5 init code that the virtio device > is already configured, and just skip it. For now, this temporary patch > (disable virtio-blk completely) works: > > > ============================================================================================== > > --- a/bindings/virtio/pci.c > +++ b/bindings/virtio/pci.c > @@ -54,7 +54,6 @@ > > > static uint32_t net_devices_found; > -static uint32_t blk_devices_found; > > #define PCI_CONF_SUBSYS_NET 1 > #define PCI_CONF_SUBSYS_BLK 2 > @@ -72,15 +71,6 @@ static void virtio_config(struct pci_config_info *pci) > log(WARN, "Solo5: PCI:%02x:%02x: not configured\n", pci->bus, > pci->dev); > break; > - case PCI_CONF_SUBSYS_BLK: > - log(INFO, "Solo5: PCI:%02x:%02x: virtio-block device, base=0x%x, > irq=%u\n", > - pci->bus, pci->dev, pci->base, pci->irq); > - if (!blk_devices_found++) > - virtio_config_block(pci); > - else > - log(WARN, "Solo5: PCI:%02x:%02x: not configured\n", pci->bus, > - pci->dev); > - break; > default: > log(WARN, "Solo5: PCI:%02x:%02x: unknown virtio device (0x%x)\n", > pci->bus, pci->dev, pci->subsys_id); > > > ============================================================================================== > > Thanks, > Ricardo > > On Mon, Oct 26, 2020 at 11:33 AM Ricardo Koller > wrote: > >> Hello, >> >> Will reproduce it and update with some findings, hopefully by the end of >> this week. >> >> Ricardo >> >> On Mon, Oct 26, 2020 at 3:48 AM Hans Ole Rafaelsen >> wrote: >> >>> Hi, >>> >>> $ qemu-system-x86_64 --version >>> QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.32) >>> Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers >>> >>> -- >>> Hans Ole >>> >>> On Mon, Oct 26, 2020 at 11:44 AM Martin Lucina >>> wrote: >>> >>>> (Re-sending with a current email for Ricardo) >>>> >>>> On Monday, 26.10.2020 at 11:37, Martin Lucina wrote: >>>> > Hi, >>>> > >>>> > On Sunday, 25.10.2020 at 13:37, Hans Ole Rafaelsen wrote: >>>> > > Hi, >>>> > > >>>> > > I have been investigating some more, and I seem to be a >>>> 'virtio-block >>>> > > device' problem. On the OpenStack cloud this device is reported >>>> when Solo5 >>>> > > boots, but not on my local installation. >>>> > > >>>> > > I changed from IDE (default) to virtio as a drive on my local >>>> installation, >>>> > > and that gives the same behaviour as on the cloud. So the behaviour >>>> can be >>>> > > shown with these two different examples. >>>> > > >>>> > > Using a IDE drive for the image: >>>> > > $ qemu-system-x86_64 -cpu Westmere -m 128 -nodefaults -no-acpi >>>> -display >>>> > > none -serial stdio -device virtio-net,netdev=n0 -netdev >>>> > > tap,id=n0,ifname=tap100,script=no,downscript=no -device >>>> isa-debug-exit >>>> > > -device lsi,id=scsi0,bus=pci.0,addr=0x9 \ >>>> > > -drive >>>> > > >>>> file=/home/hans/src/5g/mirage/repository.qcow2,format=qcow2,if=none,id=drive-ide0-0-0 >>>> > > -device >>>> ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 >>>> > > >>>> > > SYSLINUX 6.03 20171017 Copyright (C) 1994-2014 H. Peter Anvin et al >>>> > > Loading unikernel.bin... ok >>>> > > | ___| >>>> > > __| _ \ | _ \ __ \ >>>> > > \__ \ ( | | ( | ) | >>>> > > ____/\___/ _|\___/____/ >>>> > > Solo5: Bindings version v0.6.7 >>>> > > Solo5: Memory map: 128 MB addressable: >>>> > > Solo5: reserved @ (0x0 - 0xfffff) >>>> > > Solo5: text @ (0x100000 - 0x481fff) >>>> > > Solo5: rodata @ (0x482000 - 0x51dfff) >>>> > > Solo5: data @ (0x51e000 - 0x74efff) >>>> > > Solo5: heap >= 0x74f000 < stack < 0x8000000 >>>> > > Solo5: Clock source: TSC, frequency estimate is 2808856460 Hz >>>> > > Solo5: PCI:00:02: virtio-net device, base=0xc100, irq=10 >>>> > > Solo5: PCI:00:02: configured, mac=52:54:00:12:34:56, >>>> features=0x79bfffe7 >>>> > > Solo5: Application acquired 'service' as network device >>>> > > 2020-10-25 12:16:34 -00:00: INF [netif] Plugging into service with >>>> mac >>>> > > 52:54:00:12:34:56 mtu 1500 >>>> > > 2020-10-25 12:16:34 -00:00: INF [ethernet] Connected Ethernet >>>> interface >>>> > > 52:54:00:12:34:56 >>>> > > >>>> > > Using virtio drive for the image: >>>> > > $ qemu-system-x86_64 -cpu Westmere -m 128 -nodefaults -no-acpi >>>> -display >>>> > > none -serial stdio -device virtio-net,netdev=n0 -netdev >>>> > > tap,id=n0,ifname=tap100,script=no,downscript=no -device >>>> isa-debug-exit \ >>>> > > -drive >>>> > > >>>> file=/home/hans/src/hermod-5g/mirage/repository.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 >>>> > > -device >>>> > > >>>> virtio-blk-pci,scsi=off,bus=pci.0,addr=0xa,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 >>>> > > >>>> > > >>>> > > SYSLINUX 6.03 20171017 Copyright (C) 1994-2014 H. Peter Anvin et al >>>> > > Loading unikernel.bin... ok >>>> > > | ___| >>>> > > __| _ \ | _ \ __ \ >>>> > > \__ \ ( | | ( | ) | >>>> > > ____/\___/ _|\___/____/ >>>> > > Solo5: Bindings version v0.6.7 >>>> > > Solo5: Memory map: 127 MB addressable: >>>> > > Solo5: reserved @ (0x0 - 0xfffff) >>>> > > Solo5: text @ (0x100000 - 0x481fff) >>>> > > Solo5: rodata @ (0x482000 - 0x51dfff) >>>> > > Solo5: data @ (0x51e000 - 0x74efff) >>>> > > Solo5: heap >= 0x74f000 < stack < 0x7ffe000 >>>> > > Solo5: Clock source: TSC, frequency estimate is 2809165540 Hz >>>> > > Solo5: PCI:00:02: virtio-net device, base=0xc040, irq=10 >>>> > > Solo5: PCI:00:02: configured, mac=52:54:00:12:34:56, >>>> features=0x79bfffe7 >>>> > > Solo5: PCI:00:0a: virtio-block device, base=0xc000, irq=10 >>>> > > Solo5: PCI:00:0a: configured, capacity=2097152 sectors, >>>> features=0x79000e54 >>>> > > qemu-system-x86_64: virtio: zero sized buffers are not allowed >>>> > >>>> > Looks like some bug with recent QEMU and the Solo5 virtio-block >>>> > implementation. >>>> > >>>> > What QEMU version is that? >>>> > >>>> > As I wrote, the virtio target does not get much testing :-( >>>> > >>>> > > Is the problem that I need to set up handlers etc. to handle a >>>> virtio block >>>> > > device in the MirageOS application? I can't find anything about >>>> this in the >>>> > > documentation. Or might it be a bug in Solo5/MirageOS? >>>> > >>>> > No, it's a bug. >>>> > >>>> > Cc:ing Ricardo who may be able to look into it. >>>> > >>>> > Martin >>>> > >>>> >>>> --000000000000a2c77e05b30c2220 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ricardo,

Thanks for the p= atch. Now the image works at the OpenStack cloud I'm using.
<= br>
Regards,

Hans Ole
On Fri, O= ct 30, 2020 at 8:55 PM Ricardo Koller <ricarkol@gmail.com> wrote:
Hello,

Was able to reproduce= it and now have a better idea of what's going on (with a temporary fix= included). The issue happens when using qemu with a boot disk image expose= d as a virtio-blk device. The problem is that solo5 tries to configure a vi= rtio device that was already initialized/configured at VM early boot time. = Qemu gets "confused" with the second configuration attempt, throw= s the "virtio: zero sized buffers are not allowed" error and gets= stuck (somewhere that I couldn't determine).

Just in case, thes= e are all the tests I tried (using qemu v3 as v5 has an issue https://github.c= om/Solo5/solo5/issues/463). To make things simpler I've been using = the solo5 tests/test-net unikernel (c code, not mirage). You can create dis= k-net.img in solo5 using:
tests (master) [83]> ../scripts/virtio-mkim= age/solo5-virtio-mkimage.sh -f raw disk-net.img test_net/test_net.virtio
These work:
+=C2=A0boot disk image as an IDE device:
qemu-3 -dr= ive file=3Ddisk-net.img,if=3Dide,format=3Draw -cpu Westmere -m 128 -nodefau= lts -no-acpi -display none \
-serial stdio -device virtio- net,netdev= =3Dn0 -netdev tap,id=3Dn0,ifname=3Dtap100,script=3Dno,downscript=3Dno -devi= ce isa-debug-exit

+boot disk image as a virtio-scsi device (sam= e as google cloud):
qemu-3 -device virtio-scsi-pci,id=3Dscsi \
-devi= ce scsi-hd,drive=3Dhd \
-drive if=3Dnone,id=3Dhd,file=3Ddisk-net.img,fo= rmat=3Draw \
-cpu Westmere -m 128 -nodefaults -no-acpi -display none -s= erial stdio \
-device virtio-net,netdev=3Dn0 -netdev tap,id=3Dn0,ifname= =3Dtap100,script=3Dno,downscript=3Dno -device isa-debug-exit

These d= o NOT work:
+=C2=A0boot disk image as a virtio-blk device:
qemu-3 -dr= ive file=3Ddisk-net.img,if=3Dvirtio,format=3Draw -cpu Westmere -m 128 -node= faults -no-acpi -display none \
-serial stdio -device virtio-net,netdev= =3Dn0 -netdev tap,id=3Dn0,ifname=3Dtap100,script=3Dno,downscript=3Dno -devi= ce isa-debug-exit

The right fix would be to check in solo5 init code= that the virtio device is already configured, and just skip it. For now, t= his temporary patch (disable virtio-blk completely) works:

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--- a/bindings/virt= io/pci.c
+++ b/bindings/virtio/pci.c
@@ -54,7 +54,6 @@
=C2=A0
= =C2=A0
=C2=A0static uint32_t net_devices_found;
-static uint32_t blk_= devices_found;
=C2=A0
=C2=A0#define PCI_CONF_SUBSYS_NET 1
=C2=A0#d= efine PCI_CONF_SUBSYS_BLK 2
@@ -72,15 +71,6 @@ static void virtio_config= (struct pci_config_info *pci)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0log(WARN, "Solo5: PCI:%02x:%02x: not configured\n", pci->= ;bus,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pci-= >dev);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0break;
- =C2=A0 =C2=A0cas= e PCI_CONF_SUBSYS_BLK:
- =C2=A0 =C2=A0 =C2=A0 =C2=A0log(INFO, "Solo= 5: PCI:%02x:%02x: virtio-block device, base=3D0x%x, irq=3D%u\n",
- = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pci->bus, pci->dev, pci->= base, pci->irq);
- =C2=A0 =C2=A0 =C2=A0 =C2=A0if (!blk_devices_found+= +)
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0virtio_config_block(pci);<= br>- =C2=A0 =C2=A0 =C2=A0 =C2=A0else
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0log(WARN, "Solo5: PCI:%02x:%02x: not configured\n", pci= ->bus,
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pci-&= gt;dev);
- =C2=A0 =C2=A0 =C2=A0 =C2=A0break;
=C2=A0 =C2=A0 =C2=A0defa= ult:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0log(WARN, "Solo5: PCI:%02x:%= 02x: unknown virtio device (0x%x)\n",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0pci->bus, pci->dev, pci->subsys_id);

= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Thanks,Ricardo

On Mon, Oct 26, 2020 at 11:33 AM Ricardo Koller <ricarkol@gmail.com&g= t; wrote:
Hello,

Will reproduce it and update with some= findings, hopefully by the end of this week.

= Ricardo

On Mon, Oct 26, 2020 at 3:48 AM Hans Ole Rafaelsen <hrafaelsen@gmail.com= > wrote:
Hi,

$ qemu-syst= em-x86_64 --version
QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubu= ntu7.32)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project de= velopers

--
Hans Ole

On Mo= n, Oct 26, 2020 at 11:44 AM Martin Lucina <martin@lucina.net> wrote:
(Re-sending with a current email= for Ricardo)

On Monday, 26.10.2020 at=C2=A011:37, Martin Lucina wrote:
> Hi,
>
> On Sunday, 25.10.2020 at=C2=A013:37, Hans Ole Rafaelsen wrote:
> > Hi,
> >
> > I have been investigating some more, and I seem to be a 'virt= io-block
> > device' problem. On the OpenStack cloud this device is report= ed when Solo5
> > boots, but not on my local installation.
> >
> > I changed from IDE (default) to virtio as a drive on my local ins= tallation,
> > and that gives the same behaviour as on the cloud. So the behavio= ur can be
> > shown with these two different examples.
> >
> > Using a IDE drive for the image:
> > $ qemu-system-x86_64 -cpu Westmere -m 128 -nodefaults -no-acpi -d= isplay
> > none -serial stdio -device virtio-net,netdev=3Dn0 -netdev
> > tap,id=3Dn0,ifname=3Dtap100,script=3Dno,downscript=3Dno -device i= sa-debug-exit
> > -device lsi,id=3Dscsi0,bus=3Dpci.0,addr=3D0x9 \
> > -drive
> > file=3D/home/hans/src/5g/mirage/repository.qcow2,format=3Dqcow2,i= f=3Dnone,id=3Ddrive-ide0-0-0
> > -device ide-hd,bus=3Dide.0,unit=3D0,drive=3Ddrive-ide0-0-0,id=3Di= de0-0-0,bootindex=3D1
> >
> > SYSLINUX 6.03 20171017 Copyright (C) 1994-2014 H. Peter Anvin et = al
> > Loading unikernel.bin... ok
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 ___|
> >=C2=A0 =C2=A0__|=C2=A0 _ \=C2=A0 |=C2=A0 _ \ __ \
> > \__ \ (=C2=A0 =C2=A0| | (=C2=A0 =C2=A0|=C2=A0 ) |
> > ____/\___/ _|\___/____/
> > Solo5: Bindings version v0.6.7
> > Solo5: Memory map: 128 MB addressable:
> > Solo5:=C2=A0 =C2=A0reserved @ (0x0 - 0xfffff)
> > Solo5:=C2=A0 =C2=A0 =C2=A0 =C2=A0text @ (0x100000 - 0x481fff)
> > Solo5:=C2=A0 =C2=A0 =C2=A0rodata @ (0x482000 - 0x51dfff)
> > Solo5:=C2=A0 =C2=A0 =C2=A0 =C2=A0data @ (0x51e000 - 0x74efff)
> > Solo5:=C2=A0 =C2=A0 =C2=A0 =C2=A0heap >=3D 0x74f000 < stack= < 0x8000000
> > Solo5: Clock source: TSC, frequency estimate is 2808856460 Hz
> > Solo5: PCI:00:02: virtio-net device, base=3D0xc100, irq=3D10
> > Solo5: PCI:00:02: configured, mac=3D52:54:00:12:34:56, features= =3D0x79bfffe7
> > Solo5: Application acquired 'service' as network device > > 2020-10-25 12:16:34 -00:00: INF [netif] Plugging into service wit= h mac
> > 52:54:00:12:34:56 mtu 1500
> > 2020-10-25 12:16:34 -00:00: INF [ethernet] Connected Ethernet int= erface
> > 52:54:00:12:34:56
> >
> > Using virtio drive for the image:
> > $ qemu-system-x86_64 -cpu Westmere -m 128 -nodefaults -no-acpi -d= isplay
> > none -serial stdio -device virtio-net,netdev=3Dn0 -netdev
> > tap,id=3Dn0,ifname=3Dtap100,script=3Dno,downscript=3Dno -device i= sa-debug-exit \
> > -drive
> > file=3D/home/hans/src/hermod-5g/mirage/repository.qcow2,format=3D= qcow2,if=3Dnone,id=3Ddrive-virtio-disk0
> > -device
> > virtio-blk-pci,scsi=3Doff,bus=3Dpci.0,addr=3D0xa,drive=3Ddrive-vi= rtio-disk0,id=3Dvirtio-disk0,bootindex=3D1
> >
> >
> > SYSLINUX 6.03 20171017 Copyright (C) 1994-2014 H. Peter Anvin et = al
> > Loading unikernel.bin... ok
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 ___|
> >=C2=A0 =C2=A0__|=C2=A0 _ \=C2=A0 |=C2=A0 _ \ __ \
> > \__ \ (=C2=A0 =C2=A0| | (=C2=A0 =C2=A0|=C2=A0 ) |
> > ____/\___/ _|\___/____/
> > Solo5: Bindings version v0.6.7
> > Solo5: Memory map: 127 MB addressable:
> > Solo5:=C2=A0 =C2=A0reserved @ (0x0 - 0xfffff)
> > Solo5:=C2=A0 =C2=A0 =C2=A0 =C2=A0text @ (0x100000 - 0x481fff)
> > Solo5:=C2=A0 =C2=A0 =C2=A0rodata @ (0x482000 - 0x51dfff)
> > Solo5:=C2=A0 =C2=A0 =C2=A0 =C2=A0data @ (0x51e000 - 0x74efff)
> > Solo5:=C2=A0 =C2=A0 =C2=A0 =C2=A0heap >=3D 0x74f000 < stack= < 0x7ffe000
> > Solo5: Clock source: TSC, frequency estimate is 2809165540 Hz
> > Solo5: PCI:00:02: virtio-net device, base=3D0xc040, irq=3D10
> > Solo5: PCI:00:02: configured, mac=3D52:54:00:12:34:56, features= =3D0x79bfffe7
> > Solo5: PCI:00:0a: virtio-block device, base=3D0xc000, irq=3D10 > > Solo5: PCI:00:0a: configured, capacity=3D2097152 sectors, feature= s=3D0x79000e54
> > qemu-system-x86_64: virtio: zero sized buffers are not allowed >
> Looks like some bug with recent QEMU and the Solo5 virtio-block
> implementation.
>
> What QEMU version is that?
>
> As I wrote, the virtio target does not get much testing :-(
>
> > Is the problem that I need to set up handlers etc. to handle a vi= rtio block
> > device in the MirageOS application? I can't find anything abo= ut this in the
> > documentation. Or might it be a bug in Solo5/MirageOS?
>
> No, it's a bug.
>
> Cc:ing Ricardo who may be able to look into it.
>
> Martin
>

--000000000000a2c77e05b30c2220-- From mirageos-devel-bounces@lists.xenproject.org Thu Nov 05 15:05:40 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 05 Nov 2020 15:05:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.19845.45274 (Exim 4.92) (envelope-from ) id 1kagpI-0000oT-CY; Thu, 05 Nov 2020 15:05:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 19845.45274; Thu, 05 Nov 2020 15:05:24 +0000 X-BeenThere: mirageos-devel@lists.xenproject.org List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mirageos-devel-bounces@lists.xenproject.org Precedence: list Sender: "MirageOS-devel" Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kagpI-0000oM-8n; Thu, 05 Nov 2020 15:05:24 +0000 Received: by outflank-mailman (input) for mailman id 19845; Thu, 05 Nov 2020 15:05:23 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kagpH-0000oH-3N for mirageos-devel@lists.xenproject.org; Thu, 05 Nov 2020 15:05:23 +0000 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4b42ff3e-4bb4-4a7c-be07-4b24c2251953; Thu, 05 Nov 2020 15:05:21 +0000 (UTC) Received: from nodbug.lucina.net (78-141-76-187.dynamic.orange.sk [78.141.76.187]) by smtp.lucina.net (Postfix) with ESMTPSA id 4CE18122804; Thu, 5 Nov 2020 16:05:20 +0100 (CET) Received: by nodbug.lucina.net (Postfix, from userid 1000) id 3104D2684962; Thu, 5 Nov 2020 16:05:20 +0100 (CET) Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kagpH-0000oH-3N for mirageos-devel@lists.xenproject.org; Thu, 05 Nov 2020 15:05:23 +0000 X-Inumbo-ID: 4b42ff3e-4bb4-4a7c-be07-4b24c2251953 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4b42ff3e-4bb4-4a7c-be07-4b24c2251953; Thu, 05 Nov 2020 15:05:21 +0000 (UTC) Received: from nodbug.lucina.net (78-141-76-187.dynamic.orange.sk [78.141.76.187]) by smtp.lucina.net (Postfix) with ESMTPSA id 4CE18122804; Thu, 5 Nov 2020 16:05:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201811; t=1604588720; bh=O3/BO1s83yQVoDNAS0FFfbJHKJ58eZmRUJVEK4k0hZ4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=IYvuXPaXSPItWc8VszFJ1Vj1AyhV8tuDOqr2WYQzvLFHDgBEn1b0EKt6Rn+Zp15JB hDkWs59g3yba0auayIi5zEK+iXdprW2PrWSrJBdSaTXITreLz2O2upxOSOvjVbQ5Na qgXhD+qUz1G+ZkWV1fHBx0NHg2kQHUN/0zNpFjwWLA46+CqA2eiJa0q7vk8dU6unm9 cZzpGu6tGEjG8J6htiGwaotXPN6ahP5j6p/RBodB9tE6jy3RtzRJZRZHFBF34o9XjV ABQ3PlPXjDTFrb+6lo8tLmqWXzUF12ADJFoB5D8YoqBZpzmV8L1K7CT4bkpNwa40wC ElDCL0V8r2Zgw== Received: by nodbug.lucina.net (Postfix, from userid 1000) id 3104D2684962; Thu, 5 Nov 2020 16:05:20 +0100 (CET) Date: Thu, 5 Nov 2020 16:05:20 +0100 From: Martin Lucina To: Hans Ole Rafaelsen Cc: Ricardo Koller , mirageos-devel@lists.xenproject.org Subject: Re: MirageOS on OpenStack problem Message-ID: <20201105150520.GC29775@nodbug.lucina.net> Mail-Followup-To: Martin Lucina , Hans Ole Rafaelsen , Ricardo Koller , mirageos-devel@lists.xenproject.org References: <20201016121547.GA19073@nodbug.lucina.net> <20201026103746.GB11343@nodbug.lucina.net> <20201026104335.GC11343@nodbug.lucina.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Ricardo, > > Was able to reproduce it and now have a better idea of what's going on > > (with a temporary fix included). The issue happens when using qemu with a > > boot disk image exposed as a virtio-blk device. The problem is that solo5 > > tries to configure a virtio device that was already initialized/configured > > at VM early boot time. Qemu gets "confused" with the second configuration > > attempt, throws the "virtio: zero sized buffers are not allowed" error and > > gets stuck (somewhere that I couldn't determine). thanks for investigating! I've created an issue to track this, though I don't expect to have time to look into it soon: https://github.com/Solo5/solo5/issues/483 Hans, you might want to subscribe to that, I don't know your Github ID. > Thanks for the patch. Now the image works at the OpenStack cloud I'm using. In the mean time, you can work with Ricardo's patch; if you want to get that working with a MirageOS application, then do something like (assuming OPAM already set up): 1. git clone https://github.com/Solo5/solo5.git 2. apply Ricardo's workaround to solo5/ 3. opam pin add -k path solo5-bindings-virtio solo5/ 4. proceed as normal with building a Mirage application. Hope this helps, -mato From mirageos-devel-bounces@lists.xenproject.org Mon Nov 23 13:40:40 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 23 Nov 2020 13:40:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.34313.65257 (Exim 4.92) (envelope-from ) id 1khC4s-0001JF-SG; Mon, 23 Nov 2020 13:40:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 34313.65257; Mon, 23 Nov 2020 13:40:22 +0000 X-BeenThere: mirageos-devel@lists.xenproject.org List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mirageos-devel-bounces@lists.xenproject.org Precedence: list Sender: "MirageOS-devel" Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1khC4s-0001J8-Oe; Mon, 23 Nov 2020 13:40:22 +0000 Received: by outflank-mailman (input) for mailman id 34313; Mon, 23 Nov 2020 13:40:22 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1khC4s-0001J3-0L for mirageos-devel@lists.xenproject.org; Mon, 23 Nov 2020 13:40:22 +0000 Received: from mail.mehnert.org (unknown [213.73.89.200]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 6d24b8fd-0281-4d28-ab09-ec3658080ced; Mon, 23 Nov 2020 13:40:18 +0000 (UTC) Received: from [192.168.42.80] (dslb-188-102-152-045.188.102.pools.vodafone-ip.de [188.102.152.45]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "hannes@mehnert.org", Issuer "mehnert root CA" (not verified)) by mail.mehnert.org (Postfix) with ESMTPS id 347CB1B9C4 for ; Mon, 23 Nov 2020 14:40:16 +0100 (CET) Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1khC4s-0001J3-0L for mirageos-devel@lists.xenproject.org; Mon, 23 Nov 2020 13:40:22 +0000 X-Inumbo-ID: 6d24b8fd-0281-4d28-ab09-ec3658080ced Received: from mail.mehnert.org (unknown [213.73.89.200]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 6d24b8fd-0281-4d28-ab09-ec3658080ced; Mon, 23 Nov 2020 13:40:18 +0000 (UTC) Received: from [192.168.42.80] (dslb-188-102-152-045.188.102.pools.vodafone-ip.de [188.102.152.45]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "hannes@mehnert.org", Issuer "mehnert root CA" (not verified)) by mail.mehnert.org (Postfix) with ESMTPS id 347CB1B9C4 for ; Mon, 23 Nov 2020 14:40:16 +0100 (CET) From: Hannes Mehnert To: mirageos-devel@lists.xenproject.org Subject: Wednesday, 25th November 2020 is Bug Cleaning Day! Message-ID: <3749e747-3a01-c13c-97ba-e73db9b7b0a3@mehnert.org> Date: Mon, 23 Nov 2020 14:40:09 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Hi folks, We have many repositories that have lots of old and no-longer-relevant issues in them (some have even been fixed!) as well as issues that haven't gotten a reply yet from a maintainer. In preparation for the next release, I think it would be nice to take a day and do some housecleaning. Our last bug cleaning day was on 17th November 2017, and pretty successful. On Wednesday, 25th November (in two days) most people of the mirage-core team will be going through old issues and coordinating our efforts on the #mirage channel over on irc.freenode.net. I expect there to be the most activity during 10:00-18:00 UTC and maybe a bit later, but don't feel limited to that timeslot -- if you're familiar with a repository and have a bit of time, we'd love your help any time at all. Please do join us if you're free! We'll as well be watching the OCaml discord #mirage channel https://discord.com/channels/436568060288172042/519199441769594911 If you're not sure where to start, here's a link to a GitHub search for all issues in repositories owned by the Mirage organization which are open and not archived, sorted with the least recently updated first, for your editing and browsing pleasure: https://github.com/issues?q=is%3Aopen+is%3Aissue+org%3Amirage+archived%3Afalse+sort%3Aupdated-asc If you've a specific issue at your heart that you want to be solved, please show up and tell us about it. See you on Wednesday, Hannes