From mirageos-devel-bounces@lists.xenproject.org Tue Oct 13 06:44:18 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 13 Oct 2020 06:44:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.5704.16053 (Exim 4.92) (envelope-from ) id 1kSE2V-0005y9-Gr; Tue, 13 Oct 2020 06:44:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 5704.16053; Tue, 13 Oct 2020 06:44:03 +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 1kSE2V-0005y2-Ci; Tue, 13 Oct 2020 06:44:03 +0000 Received: by outflank-mailman (input) for mailman id 5704; Sun, 11 Oct 2020 17:55:44 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kRfZP-0003I1-Ud for mirageos-devel@lists.xenproject.org; Sun, 11 Oct 2020 17:55:44 +0000 Received: from mail-ed1-x529.google.com (unknown [2a00:1450:4864:20::529]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 987600d2-90c5-4b69-a6f4-15c1409ae6e9; Sun, 11 Oct 2020 17:55:42 +0000 (UTC) Received: by mail-ed1-x529.google.com with SMTP id l24so14577177edj.8 for ; Sun, 11 Oct 2020 10:55:42 -0700 (PDT) Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kRfZP-0003I1-Ud for mirageos-devel@lists.xenproject.org; Sun, 11 Oct 2020 17:55:44 +0000 X-Inumbo-ID: 987600d2-90c5-4b69-a6f4-15c1409ae6e9 Received: from mail-ed1-x529.google.com (unknown [2a00:1450:4864:20::529]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 987600d2-90c5-4b69-a6f4-15c1409ae6e9; Sun, 11 Oct 2020 17:55:42 +0000 (UTC) Received: by mail-ed1-x529.google.com with SMTP id l24so14577177edj.8 for ; Sun, 11 Oct 2020 10:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=3W7mE5vR86d914BiFowRYnScRXHBhd6XH9fniytDVFk=; b=OofDd1X6v++MLeB4JN0WaBHC0IIqwBRgbDtBtsSdLOMbXmkUX5ZDsG9xkvgf4X/xLa j7GZEgA+wiBw9ns74ZoWfQBkmcf8wZCOC8gbJq2V/HhgyI2EJ1OGXIiuB7Vp5GdfMXxh 6eAlwg6qrQtP+i9fhyDRDQ5JhzB14zhTrNwJ59ImMQO3o9Wf8OBx05DlusFslvTz9rnr DmWTbCo4K0xzB65K95bVKaDVMuusF0UXi+wXeIef4BX2jeeU5eYhj1dKZtkPjbwKmGxp ozi2ynC0i+YQvfU/fcLTxhelju/GzLchTQ3FC4anXvWjxKQiO5es/cptZi31e6ot3j6v R+HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=3W7mE5vR86d914BiFowRYnScRXHBhd6XH9fniytDVFk=; b=Sofziuy8uylMlWE1jOnlk1CnIdBmQVFmA5Ps3pijq7qpgWWo01YrFJSc4fiAAg3N/u tOD5lSlSU9DjN1fLK5XdXidmJesNnht0X+Ch50NWmNsTNHhHthPz0Hb9KpVpe1TZ7hsw KqOq+z1TnJ1/au8uIu/XNobkG+sI3KmxZwBr0a/tqDDzGb1zj3BY7kE3JtNyRRPs5cah ypiQiMFIAjbmjyI8AMHmp7dF13IlWuIXE9anb+ZKzCyx8Bw5aXMV2uzhFwKNQnb7rPF+ oGEaPTpQLEUg3byO/Attc0OIrtlGJZZgrdqYj9QILmRrQ7tPy1Bt2aikP0oCHHDnvghf XVGw== X-Gm-Message-State: AOAM530nQPlOwPMnn7X5KclZfmV3cqUeqE6Qe0HwT0pEakRWy36D6RtY 15ni/kKCoxLb7Zma6r4Jb/QgAuMCqkZ+dRj0iS8vY0KYY499SA== X-Google-Smtp-Source: ABdhPJwxx9lXNAjW8bop1nuz2iF9Ixz/H33LpoTC9kb68St2SQqJP2r40pJ6UM5CPmKdt/31FJueYSLp6qSVaIG1dtQ= X-Received: by 2002:a50:9ec6:: with SMTP id a64mr10148081edf.382.1602438941482; Sun, 11 Oct 2020 10:55:41 -0700 (PDT) MIME-Version: 1.0 From: Hans Ole Rafaelsen Date: Sun, 11 Oct 2020 19:55:30 +0200 Message-ID: Subject: MirageOS on OpenStack problem To: mirageos-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000e1a71805b168e3d6" --000000000000e1a71805b168e3d6 Content-Type: text/plain; charset="UTF-8" Hi, I'm trying to run some of the tutorial examples on OpenStack. This is a "Nokia AirFrame Cloud Infrastructure" with "OpenStack Compute version 17.0.7-1" I have built a virtio target and created a qcow2 image. When running this on OpenStack it seems to start the Solo5 execution environment, but the MirageOS application does not seem to start. The log only show: SYSLINUX 6.03 20171017 Copyright (C) 1994-2014 H. Peter Anvin et al Loading unikernel.bin... ok | ___| __| _ \ | _ \ __ \ \__ \ ( | | ( | ) | ____/\___/ _|\___/____/ Solo5: Bindings version v0.6.6 Solo5: Memory map: 1024 MB addressable: Solo5: reserved @ (0x0 - 0xfffff) Solo5: text @ (0x100000 - 0x47dfff) Solo5: rodata @ (0x47e000 - 0x519fff) Solo5: data @ (0x51a000 - 0x74afff) Solo5: heap >= 0x74b000 < stack < 0x40000000 Solo5: Clock source: KVM paravirtualized clock Solo5: PCI:00:03: virtio-net device, base=0xc060, irq=11 Solo5: PCI:00:03: configured, mac=fa:16:3e:a6:51:b7, features=0x48bf81a6 Solo5: PCI:00:04: virtio-block device, base=0xc000, irq=11 Solo5: PCI:00:04: configured, capacity=125829120 sectors, features=0x79000e54 Not sure if it is a problem with getting the log output from the application or if it is not starting at all. The cloud infrastructure says the VM is active, but it does not show the actual resource usage of the VM, so it is hard to say what is going on. For network applications it does not respond to ping, so it seems like it is not running. The qcow2 image runs fine on a local (Ubuntu 18.04 host) qemu/kvm VM and I have no problem running other qcow2 images (Ubuntu) on the OpenStack cloud. Is there some limitation on the images created with mirage/solo5 that prevents them from running on the OpenStack platform? Any tips on how to investigate this problem? Regards, Hans Ole Rafaelsen --000000000000e1a71805b168e3d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I'm trying to run so= me of the tutorial examples on OpenStack. This is a "Nokia AirFrame Cl= oud Infrastructure" with "OpenStack Compute version 17.0.7-1"= ;

I have built a virtio target and created a qcow2= image.

When running this on OpenStack it seems to= start the Solo5 execution environment, but the MirageOS application does n= ot seem to start. The log only show:
SY=
SLINUX 6.03 20171017 Copyright (C) 1994-2014 H. Peter Anvin et al
Loading unikernel.bin... ok
            |      ___|
  __|  _ \  |  _ \ __ \
\__ \ (   | | (   |  ) |
____/\___/ _|\___/____/
Solo5: Bindings version v0.6.6
Solo5: Memory map: 1024 MB addressable:
Solo5:   reserved @ (0x0 - 0xfffff)
Solo5:       text @ (0x100000 - 0x47dfff)
Solo5:     rodata @ (0x47e000 - 0x519fff)
Solo5:       data @ (0x51a000 - 0x74afff)
Solo5:       heap >=3D 0x74b000 < stack < 0x40000000
Solo5: Clock source: KVM paravirtualized clock
Solo5: PCI:00:03: virtio-net device, base=3D0xc060, irq=3D11
Solo5: PCI:00:03: configured, mac=3Dfa:16:3e:a6:51:b7, features=3D0x48bf81a=
6
Solo5: PCI:00:04: virtio-block device, base=3D0xc000, irq=3D11
Solo5: PCI:00:04: configured, capacity=3D125829120 sectors, features=3D0x79=
000e54
Not sure if it is a problem with getting the log out= put from the application or if it is not starting at all. The cloud infrast= ructure says the VM is active, but it does not show the actual resource usa= ge of the VM, so it is hard to say what is going on.
For netw= ork applications it does not respond to ping, so it seems like it is not ru= nning.

The qcow2 image runs fine on a local (Ubunt= u 18.04 host) qemu/kvm VM and I have no problem running other qcow2 images = (Ubuntu) on the OpenStack cloud.

Is there some lim= itation on the images created with mirage/solo5 that prevents them from run= ning on the OpenStack platform?

Any tips on how to= investigate this problem?

Regards,

Hans Ole Rafaelsen
--000000000000e1a71805b168e3d6-- From mirageos-devel-bounces@lists.xenproject.org Fri Oct 16 12:34:22 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 16 Oct 2020 12:34:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.8068.21473 (Exim 4.92) (envelope-from ) id 1kTOvo-0001t7-S6; Fri, 16 Oct 2020 12:34:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 8068.21473; Fri, 16 Oct 2020 12:34:00 +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 1kTOvo-0001t0-OS; Fri, 16 Oct 2020 12:34:00 +0000 Received: by outflank-mailman (input) for mailman id 8068; Fri, 16 Oct 2020 12:33:59 +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 1kTOvn-0001ss-D0 for mirageos-devel@lists.xenproject.org; Fri, 16 Oct 2020 12:33:59 +0000 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3857695e-ed87-4d3b-a25c-f23ec2cf6442; Fri, 16 Oct 2020 12:33:58 +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 0F62D122804; Fri, 16 Oct 2020 14:15:48 +0200 (CEST) Received: by nodbug.lucina.net (Postfix, from userid 1000) id CCAF52684962; Fri, 16 Oct 2020 14:15:47 +0200 (CEST) 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 1kTOvn-0001ss-D0 for mirageos-devel@lists.xenproject.org; Fri, 16 Oct 2020 12:33:59 +0000 X-Inumbo-ID: 3857695e-ed87-4d3b-a25c-f23ec2cf6442 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3857695e-ed87-4d3b-a25c-f23ec2cf6442; Fri, 16 Oct 2020 12:33:58 +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 0F62D122804; Fri, 16 Oct 2020 14:15:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201811; t=1602850548; bh=cLSC+C23I2HG5eaPp/VfIe+mXqv6+8BGQ84Pz5ydiiY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Oq4GEmxjatPC9GGmu3JxQqSHhab629eyM85vOX5BooMtmLddZauKGQXlUB5BW3/nB 3K/ZPyZZyS5V2z2TZfwewV7e4hTR7BuK25oIDqGQbKse0NA9vdo6o4kfc04YlI61iG 8xqaD+dtgFyefbzluRdI8zq9UankjQ+TAx+QYHvjIENxpk0xRVVPoCEHwlaj5EIpqM oW0yOXl34kfUyAAc00legNFcPhC01tMGC4QdB7rayYvtJUL/tpgJwZ6M8JfH4fjFfc +ZpMj6lNmTf9FQE5fZOGdY0dFLTwZCkQ/6weRfW1Tj6XbqTpqxrpQdTwHKbefO1LpK RCPteqfKhxMrA== Received: by nodbug.lucina.net (Postfix, from userid 1000) id CCAF52684962; Fri, 16 Oct 2020 14:15:47 +0200 (CEST) Date: Fri, 16 Oct 2020 14:15:47 +0200 From: Martin Lucina To: Hans Ole Rafaelsen Cc: mirageos-devel@lists.xenproject.org Subject: Re: MirageOS on OpenStack problem Message-ID: <20201016121547.GA19073@nodbug.lucina.net> Mail-Followup-To: Martin Lucina , Hans Ole Rafaelsen , mirageos-devel@lists.xenproject.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Hi Hans, On Sunday, 11.10.2020 at 19:55, Hans Ole Rafaelsen wrote: > Hi, > > I'm trying to run some of the tutorial examples on OpenStack. This is a > "Nokia AirFrame Cloud Infrastructure" with "OpenStack Compute version > 17.0.7-1" Any idea what QEMU version that uses internally? > > I have built a virtio target and created a qcow2 image. > > When running this on OpenStack it seems to start the Solo5 execution > environment, but the MirageOS application does not seem to start. The log > only show: Which example, specifically? > SYSLINUX 6.03 20171017 Copyright (C) 1994-2014 H. Peter Anvin et al > Loading unikernel.bin... ok > | ___| > __| _ \ | _ \ __ \ > \__ \ ( | | ( | ) | > ____/\___/ _|\___/____/ > Solo5: Bindings version v0.6.6 > Solo5: Memory map: 1024 MB addressable: > Solo5: reserved @ (0x0 - 0xfffff) > Solo5: text @ (0x100000 - 0x47dfff) > Solo5: rodata @ (0x47e000 - 0x519fff) > Solo5: data @ (0x51a000 - 0x74afff) > Solo5: heap >= 0x74b000 < stack < 0x40000000 > Solo5: Clock source: KVM paravirtualized clock > Solo5: PCI:00:03: virtio-net device, base=0xc060, irq=11 > Solo5: PCI:00:03: configured, mac=fa:16:3e:a6:51:b7, features=0x48bf81a6 > Solo5: PCI:00:04: virtio-block device, base=0xc000, irq=11 > Solo5: PCI:00:04: configured, capacity=125829120 sectors, features=0x79000e54 > > Not sure if it is a problem with getting the log output from the > application or if it is not starting at all. The cloud infrastructure says > the VM is active, but it does not show the actual resource usage of the VM, > so it is hard to say what is going on. > For network applications it does not respond to ping, so it seems like it > is not running. Try adding "--logs=*:debug" to the kernel command line. > > The qcow2 image runs fine on a local (Ubuntu 18.04 host) qemu/kvm VM and I > have no problem running other qcow2 images (Ubuntu) on the OpenStack cloud. > > Is there some limitation on the images created with mirage/solo5 that > prevents them from running on the OpenStack platform? I suspect no one's tried on OpenStack. Also, be aware that the virtio target is somewhat limited; all the exciting stuff is going on in the other Solo5-based targets. -mato > > Any tips on how to investigate this problem? > > Regards, > > Hans Ole Rafaelsen From mirageos-devel-bounces@lists.xenproject.org Sat Oct 17 18:04:55 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 17 Oct 2020 18:04:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.8410.22488 (Exim 4.92) (envelope-from ) id 1kTqZL-00032D-Tw; Sat, 17 Oct 2020 18:04:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 8410.22488; Sat, 17 Oct 2020 18:04:39 +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 1kTqZL-000326-Q5; Sat, 17 Oct 2020 18:04:39 +0000 Received: by outflank-mailman (input) for mailman id 8410; Sat, 17 Oct 2020 18:04:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kTqZL-000321-7Z for mirageos-devel@lists.xenproject.org; Sat, 17 Oct 2020 18:04:39 +0000 Received: from mail-ej1-x629.google.com (unknown [2a00:1450:4864:20::629]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d178aa85-1a94-4e22-b6de-11565cb7eb00; Sat, 17 Oct 2020 18:04:37 +0000 (UTC) Received: by mail-ej1-x629.google.com with SMTP id dt13so8017431ejb.12 for ; Sat, 17 Oct 2020 11:04:37 -0700 (PDT) Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kTqZL-000321-7Z for mirageos-devel@lists.xenproject.org; Sat, 17 Oct 2020 18:04:39 +0000 X-Inumbo-ID: d178aa85-1a94-4e22-b6de-11565cb7eb00 Received: from mail-ej1-x629.google.com (unknown [2a00:1450:4864:20::629]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d178aa85-1a94-4e22-b6de-11565cb7eb00; Sat, 17 Oct 2020 18:04:37 +0000 (UTC) Received: by mail-ej1-x629.google.com with SMTP id dt13so8017431ejb.12 for ; Sat, 17 Oct 2020 11:04:37 -0700 (PDT) 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; bh=XL3j9haI0Zgz6WEFgzXyx2kCdJu+sDuaFR7SmI4/ys4=; b=Wo6SkpZyNAyH40nuK5jSJCrBya7LiRfxN6lgjhZOnkHhnLdD/JSAlh9tj0vRTJ4UZ3 W/JH7kIHTaMwPSsGVehCWOJwDWtjm5SYBOusToCzVFkJq0VzOJADiR2mBLgKb4wLvYs6 FqQ9G0tqMt5mD3gm5Nq7I1wH1nFt6iLC+LOe5P9m9a2t7q02FVhnmEuRkQrV6cCC71ar pmTWZD5AHF8YHXHzaJ/nP9WlRreHI/0gPow3JVGG1hKyIw6SG+UtOR4Rbd6RmphL+aq+ 9vEXZ+3CdYwa3QO9kTN0CChF6MgLV8dWqnIteN/tCr/y2HOKOMqaZZ6ANzXrB8RWmC5B 99Gw== 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; bh=XL3j9haI0Zgz6WEFgzXyx2kCdJu+sDuaFR7SmI4/ys4=; b=UWthD21loYJuOOuoyNsf+uKetDONXbeF47ERMjYRIuTV9ZYI+IrNNU9lDM3Y9yowdV SYgaYWZv3PNvnsI2gikltwYcB0DXwpDDCey4ezCyCEcYL0K7GPTwnghZbi99srESuCvK 4uTHtQYZ3As05ZcDxLlnr/ZM4reB0te6capGmbDzhaMlCChB3IZ61bBFr/DPZWiL8/cT xX16KKm47W+c1BKdTiDVIAoNR+X36Q5kOszvnij3+9/MR6WeBUFiqAEWwjxNAEF+/b5n GjioShm2bz5S8H9ZLWTZB6GQxYBcjbBDcPWz0CdMVvR//7JGBCGucYAgWImPoZ6yPQ0y HXvg== X-Gm-Message-State: AOAM533WUaFUlnYT4k9rW1hprD2whx0x3J33Koq8JDl300CmQG8QRrNk n2B7yxlzdQmP4iQjFhVX6sRIGm94RmaQUhZ0nLk= X-Google-Smtp-Source: ABdhPJykd/lRQN62uBEyB2CAxVtl9gJmFAuGyKKcy/+Xt189fZIrDd+EG5RQxlAcGtpFXSL9vi2bE1TZuyjAk8JeXQw= X-Received: by 2002:a17:906:ad5:: with SMTP id z21mr9229585ejf.461.1602957876678; Sat, 17 Oct 2020 11:04:36 -0700 (PDT) MIME-Version: 1.0 References: <20201016121547.GA19073@nodbug.lucina.net> In-Reply-To: <20201016121547.GA19073@nodbug.lucina.net> From: Hans Ole Rafaelsen Date: Sat, 17 Oct 2020 20:04:25 +0200 Message-ID: Subject: Re: MirageOS on OpenStack problem To: Martin Lucina , Hans Ole Rafaelsen , mirageos-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000d457f905b1e1b607" --000000000000d457f905b1e1b607 Content-Type: text/plain; charset="UTF-8" Hi Martin, Thanks for your answer. On Fri, Oct 16, 2020 at 2:15 PM Martin Lucina wrote: > Hi Hans, > > On Sunday, 11.10.2020 at 19:55, Hans Ole Rafaelsen wrote: > > Hi, > > > > I'm trying to run some of the tutorial examples on OpenStack. This is a > > "Nokia AirFrame Cloud Infrastructure" with "OpenStack Compute version > > 17.0.7-1" > > Any idea what QEMU version that uses internally? > I have asked the provider. I'll let you know if I get a reply. > > > > I have built a virtio target and created a qcow2 image. > > > > When running this on OpenStack it seems to start the Solo5 execution > > environment, but the MirageOS application does not seem to start. The log > > only show: > > Which example, specifically? > First the network example, and later the "hello world" example, taken from https://github.com/mirage/mirage-skeleton > > SYSLINUX 6.03 20171017 Copyright (C) 1994-2014 H. Peter Anvin et al > > Loading unikernel.bin... ok > > | ___| > > __| _ \ | _ \ __ \ > > \__ \ ( | | ( | ) | > > ____/\___/ _|\___/____/ > > Solo5: Bindings version v0.6.6 > > Solo5: Memory map: 1024 MB addressable: > > Solo5: reserved @ (0x0 - 0xfffff) > > Solo5: text @ (0x100000 - 0x47dfff) > > Solo5: rodata @ (0x47e000 - 0x519fff) > > Solo5: data @ (0x51a000 - 0x74afff) > > Solo5: heap >= 0x74b000 < stack < 0x40000000 > > Solo5: Clock source: KVM paravirtualized clock > > Solo5: PCI:00:03: virtio-net device, base=0xc060, irq=11 > > Solo5: PCI:00:03: configured, mac=fa:16:3e:a6:51:b7, features=0x48bf81a6 > > Solo5: PCI:00:04: virtio-block device, base=0xc000, irq=11 > > Solo5: PCI:00:04: configured, capacity=125829120 sectors, > features=0x79000e54 > > > > Not sure if it is a problem with getting the log output from the > > application or if it is not starting at all. The cloud infrastructure > says > > the VM is active, but it does not show the actual resource usage of the > VM, > > so it is hard to say what is going on. > > For network applications it does not respond to ping, so it seems like it > > is not running. > > Try adding "--logs=*:debug" to the kernel command line. > I tried adding it during the "mirage configure" step. On the local qemu VM I get additional debugging info, but on the OpenStack cloud I get the same result. No logs from the application itself. > > > > > The qcow2 image runs fine on a local (Ubuntu 18.04 host) qemu/kvm VM and > I > > have no problem running other qcow2 images (Ubuntu) on the OpenStack > cloud. > > > > Is there some limitation on the images created with mirage/solo5 that > > prevents them from running on the OpenStack platform? > > I suspect no one's tried on OpenStack. Also, be aware that the virtio > target is somewhat limited; all the exciting stuff is going on in the other > Solo5-based targets. > > I tried another post about that on the mailing list, but it seems like it has got stuck. (This post took 2 days before showing up on the list.) Is there some way to make a hvt target to run on qemu/kvm? -- Hans Ole -mato > > > > > Any tips on how to investigate this problem? > > > > Regards, > > > > Hans Ole Rafaelsen > --000000000000d457f905b1e1b607 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin,

Thanks for yo= ur answer.

On Fri, Oct 16, 2020 at 2:15 PM Martin Lucina <martin@lucina.net> wrote:
=
Hi Hans,

On Sunday, 11.10.2020 at=C2=A019:55, Hans Ole Rafaelsen wrote:
> Hi,
>
> I'm trying to run some of the tutorial examples on OpenStack. This= is a
> "Nokia AirFrame Cloud Infrastructure" with "OpenStack C= ompute version
> 17.0.7-1"

Any idea what QEMU version that uses internally?
I hav= e asked the provider. I'll let you know if I get a reply.

>
> I have built a virtio target and created a qcow2 image.
>
> When running this on OpenStack it seems to start the Solo5 execution > environment, but the MirageOS application does not seem to start. The = log
> only show:

Which example, specifically?
First the network example= , and later the "hello world" example, taken from https://github.com/mirage/mirage-ske= leton


> 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.6
> Solo5: Memory map: 1024 MB addressable:
> Solo5:=C2=A0 =C2=A0reserved @ (0x0 - 0xfffff)
> Solo5:=C2=A0 =C2=A0 =C2=A0 =C2=A0text @ (0x100000 - 0x47dfff)
> Solo5:=C2=A0 =C2=A0 =C2=A0rodata @ (0x47e000 - 0x519fff)
> Solo5:=C2=A0 =C2=A0 =C2=A0 =C2=A0data @ (0x51a000 - 0x74afff)
> Solo5:=C2=A0 =C2=A0 =C2=A0 =C2=A0heap >=3D 0x74b000 < stack <= 0x40000000
> Solo5: Clock source: KVM paravirtualized clock
> Solo5: PCI:00:03: virtio-net device, base=3D0xc060, irq=3D11
> Solo5: PCI:00:03: configured, mac=3Dfa:16:3e:a6:51:b7, features=3D0x48= bf81a6
> Solo5: PCI:00:04: virtio-block device, base=3D0xc000, irq=3D11
> Solo5: PCI:00:04: configured, capacity=3D125829120 sectors, features= =3D0x79000e54
>
> Not sure if it is a problem with getting the log output from the
> application or if it is not starting at all. The cloud infrastructure = says
> the VM is active, but it does not show the actual resource usage of th= e VM,
> so it is hard to say what is going on.
> For network applications it does not respond to ping, so it seems like= it
> is not running.

Try adding "--logs=3D*:debug" to the kernel command line.
I tried adding it during the "mirage configure" ste= p. On the local qemu VM I get additional debugging info, but on the OpenSta= ck cloud I get the same result. No logs from the application itself.
=C2=A0

>
> The qcow2 image runs fine on a local (Ubuntu 18.04 host) qemu/kvm VM a= nd I
> have no problem running other qcow2 images (Ubuntu) on the OpenStack c= loud.
>
> Is there some limitation on the images created with mirage/solo5 that<= br> > prevents them from running on the OpenStack platform?

I suspect no one's tried on OpenStack. Also, be aware that the virtio target is somewhat limited; all the exciting stuff is going on in the other=
Solo5-based targets.

I tried another post about that on the mailing list, = but it seems like it has got stuck. (This post took 2 days before showing u= p on the list.)=C2=A0

Is there some way to make a = hvt target to run on qemu/kvm?

--
H= ans Ole

-mato

>
> Any tips on how to investigate this problem?
>
> Regards,
>
> Hans Ole Rafaelsen
--000000000000d457f905b1e1b607-- From mirageos-devel-bounces@lists.xenproject.org Sat Oct 24 06:34:22 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 24 Oct 2020 06:34:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.11461.30403 (Exim 4.92) (envelope-from ) id 1kWD7r-00016f-FM; Sat, 24 Oct 2020 06:34:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 11461.30403; Sat, 24 Oct 2020 06:34:03 +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 1kWD7r-00016Y-BP; Sat, 24 Oct 2020 06:34:03 +0000 Received: by outflank-mailman (input) for mailman id 11461; Sat, 24 Oct 2020 06:34:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kWD7q-00016T-ED for mirageos-devel@lists.xenproject.org; Sat, 24 Oct 2020 06:34:02 +0000 Received: from mail-ej1-x630.google.com (unknown [2a00:1450:4864:20::630]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6232fa6c-7a35-4123-b866-b2fad09e1b41; Sat, 24 Oct 2020 06:34:01 +0000 (UTC) Received: by mail-ej1-x630.google.com with SMTP id w27so5420559ejb.3 for ; Fri, 23 Oct 2020 23:34:01 -0700 (PDT) Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kWD7q-00016T-ED for mirageos-devel@lists.xenproject.org; Sat, 24 Oct 2020 06:34:02 +0000 X-Inumbo-ID: 6232fa6c-7a35-4123-b866-b2fad09e1b41 Received: from mail-ej1-x630.google.com (unknown [2a00:1450:4864:20::630]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6232fa6c-7a35-4123-b866-b2fad09e1b41; Sat, 24 Oct 2020 06:34:01 +0000 (UTC) Received: by mail-ej1-x630.google.com with SMTP id w27so5420559ejb.3 for ; Fri, 23 Oct 2020 23:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=CW9r0kFaaSIkRr4az9oUmi5XXCBLZJWFUAUkk9iFB14=; b=VUZeKx7X0WRuSnI1EYvsMQbn82NqTqWyaiGwO8lVNwN2kmvJ6pP9bm9x0KBT1E9vHy OSe2zm0iq4eKfTEE+AIWP0YcsyX7HtgaczShNUeaXFUJjBdv3+RuEpLCutTf8SFQZVjZ 56Xj7FdR51wMvkl2FBStFnEHBCLc15AxpKQyk3FYlnehqDnplbM/nbG8S+ssDwV1zmg8 8563X6M5rbCmETJ89EBZkdk6SawcEVI88Nkz9HjrTWPVeIO8emo2Gm1CXN4cW5UDwU8s mkiO6KpF/IfZws+N81l1vkJk+S9UZDljlf0ua8+uYwvXf48D4+mjEVqbxI/cNOsR3iBT O9qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=CW9r0kFaaSIkRr4az9oUmi5XXCBLZJWFUAUkk9iFB14=; b=izzqY4dfaiFiCXQBMfwmplV55vSmZABp2/tUhfz+wnYvkIZd3XK7zBSFDe8nmINtUX bneSFjs1BDb7OKlzrnPS980XjXQWUSIk0978i7Z+6QLFJRiNEfxibaw2smM5GP7QrZBM 9br3uknRgxh+7zORmqlSxWIy+vfryPpW5R3Ib+pFL2BTHOnTcOqhUEomU0IH5L/GzwiZ nRBNaTuB/6NbS4DpAZjEJanMuZuh57wEqREiLnhW8eeq/ditlz4/zOUURwgVYQ/y+k6J fs3swNoO1QZ9lmzfFg5Rcy5YBVXiqKFnu8y0wW739cPZaodmt+9UiF5AUL9yOpR2axzI wtBA== X-Gm-Message-State: AOAM530TqpmCilwHMcC2UuTo1yEB+VJNRnmeUITI2YBDgAlzHTF9B4QS naMwt/a0bcAdZGIbvCph1qkooqHRq+FfkvwpGawmUi97Xug= X-Google-Smtp-Source: ABdhPJxKqwUSUuBOdE9n+aTH1WL0Fe1Og7OPOA5H1FqBaPg+pyCJGifsCA7s0uxuTDUxgykMPjSmSpvPJUyU1/yj14c= X-Received: by 2002:a17:906:7844:: with SMTP id p4mr5506044ejm.26.1603521239963; Fri, 23 Oct 2020 23:33:59 -0700 (PDT) MIME-Version: 1.0 From: Hans Ole Rafaelsen Date: Sat, 24 Oct 2020 08:33:48 +0200 Message-ID: Subject: How do I run hvt targets on qemu/kvm? To: mirageos-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000e5dd7f05b264e1d9" --000000000000e5dd7f05b264e1d9 Content-Type: text/plain; charset="UTF-8" Hi, When reading the MirageOS tutorials/documentation it seems like virtio target has some limitations. E.g. only one network interface supported. >From the tutorials I get the impression that virtio will have limited support in the future, while hvt seems to be better supported. Making virtio targets run on qemu/kvm is documented and quite straightforward . But I can not find any way to make hvt targets run on qemu/kvm. Is there some way to make hvt targets run on qemu/kvm? Regards, Hans Ole Rafaelsen --000000000000e5dd7f05b264e1d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

When reading the Mira= geOS=20 tutorials/documentation it seems like virtio target has some=20 limitations. E.g. only one network interface supported. From the=20 tutorials I get the impression that virtio will have limited support in=20 the future, while hvt seems to be better supported.

Making virtio targets run on qemu/kvm is documented and quite straightforward . But I can not find any way to make hvt targets run on qemu/kvm.
=
Is there some way to make hvt targets run on qemu/kvm?
=

Regards,

Hans Ole Rafaelsen
--000000000000e5dd7f05b264e1d9-- From mirageos-devel-bounces@lists.xenproject.org Sat Oct 24 09:22:27 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 24 Oct 2020 09:22:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.11527.30591 (Exim 4.92) (envelope-from ) id 1kWFke-0002Da-Op; Sat, 24 Oct 2020 09:22:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 11527.30591; Sat, 24 Oct 2020 09:22:16 +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 1kWFke-0002DT-Kv; Sat, 24 Oct 2020 09:22:16 +0000 Received: by outflank-mailman (input) for mailman id 11527; Sat, 24 Oct 2020 09:22:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kWFkd-0002DM-2p for mirageos-devel@lists.xenproject.org; Sat, 24 Oct 2020 09:22:15 +0000 Received: from mail.mehnert.org (unknown [213.73.89.200]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 71cd31e1-e564-44a3-b50e-7d40b8e9184c; Sat, 24 Oct 2020 09:22:13 +0000 (UTC) Received: from [192.168.178.36] (pd95f5e1b.dip0.t-ipconnect.de [217.95.94.27]) (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 3D1F421382 for ; Sat, 24 Oct 2020 10:57:15 +0200 (CEST) Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kWFkd-0002DM-2p for mirageos-devel@lists.xenproject.org; Sat, 24 Oct 2020 09:22:15 +0000 X-Inumbo-ID: 71cd31e1-e564-44a3-b50e-7d40b8e9184c Received: from mail.mehnert.org (unknown [213.73.89.200]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 71cd31e1-e564-44a3-b50e-7d40b8e9184c; Sat, 24 Oct 2020 09:22:13 +0000 (UTC) Received: from [192.168.178.36] (pd95f5e1b.dip0.t-ipconnect.de [217.95.94.27]) (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 3D1F421382 for ; Sat, 24 Oct 2020 10:57:15 +0200 (CEST) Subject: Re: How do I run hvt targets on qemu/kvm? To: mirageos-devel@lists.xenproject.org References: From: Hannes Mehnert Message-ID: Date: Sat, 24 Oct 2020 10:57:07 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Dear Hans Ole, On 24/10/2020 08:33, Hans Ole Rafaelsen wrote: > When reading the MirageOS tutorials/documentation it seems like virtio > target has some limitations. E.g. only one network interface supported. > From the tutorials I get the impression that virtio will have limited > support in the future, while hvt seems to be better supported. > > Making virtio targets run on qemu/kvm is documented and quite > straightforward . But I can not find any way to make hvt targets run on > qemu/kvm. > > Is there some way to make hvt targets run on qemu/kvm? In order to run hvt unikernels, you need a custom "tender" named solo5-hvt on the host system instead of qemu (qemu uses virtio, solo5-hvt a custom device setup). The binary is built when you compile solo5 (i.e. download / clone https://github.com/solo5/solo5). You can start your unikernel with something like `solo5-hvt --net:service=tapX -- network.hvt --ipv4=10.0.0.2/24`. If you're not in control of the host system, or would like to use an intermediate layer / orchestration system, please don't hesitate to provide further details, and let us discuss a possible solution. Best, hannes From mirageos-devel-bounces@lists.xenproject.org Sat Oct 24 09:25:45 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 24 Oct 2020 09:25:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.11529.30595 (Exim 4.92) (envelope-from ) id 1kWFo0-0002Le-22; Sat, 24 Oct 2020 09:25:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 11529.30595; Sat, 24 Oct 2020 09:25:44 +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 1kWFnz-0002LX-VP; Sat, 24 Oct 2020 09:25:43 +0000 Received: by outflank-mailman (input) for mailman id 11529; Sat, 24 Oct 2020 09:25:42 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kWFny-0002LS-OF for mirageos-devel@lists.xenproject.org; Sat, 24 Oct 2020 09:25:42 +0000 Received: from mail-il1-x142.google.com (unknown [2607:f8b0:4864:20::142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id de77ad5a-8e19-4145-b756-23a8c6905d31; Sat, 24 Oct 2020 09:25:41 +0000 (UTC) Received: by mail-il1-x142.google.com with SMTP id w17so3743786ilg.8 for ; Sat, 24 Oct 2020 02:25:41 -0700 (PDT) Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kWFny-0002LS-OF for mirageos-devel@lists.xenproject.org; Sat, 24 Oct 2020 09:25:42 +0000 X-Inumbo-ID: de77ad5a-8e19-4145-b756-23a8c6905d31 Received: from mail-il1-x142.google.com (unknown [2607:f8b0:4864:20::142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id de77ad5a-8e19-4145-b756-23a8c6905d31; Sat, 24 Oct 2020 09:25:41 +0000 (UTC) Received: by mail-il1-x142.google.com with SMTP id w17so3743786ilg.8 for ; Sat, 24 Oct 2020 02:25:41 -0700 (PDT) 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=vKWemX/bSt2OXDa/nfVCxMj69rCJG0vwGi7S/72nnEo=; b=AZZy85KpalRoGrgWYrZjz2NyafxU16KeGXTNc/xNVyGCIUJN7WfCkiXINWXVrXFBYf /OhEIZfKEAOOvUvqs3Nh4dWA2xQjRVhROZTiwO1ZhuLR5nLTgOZFsJKtLE5+LrmsfVXU 212juQisPf723TqUj64bgSp/ZfQDNhZPgEF9K3wkUwhRO/pB1k/t8ISAxVEo+9cM1yXg GCKyUDw68JGwHZywnTyESYoM5/qFUluI0FcbalLP94dAfN2fMBbTp2u71LHCyjAgt9z9 Hp2+M9T20bTrXkmIxJ/w+yI6OfdczAMJB6GeL0dYwHlancrxUK/2CjC0rF7VOGYSG4Ct +a4Q== 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=vKWemX/bSt2OXDa/nfVCxMj69rCJG0vwGi7S/72nnEo=; b=AqTjDvRqJDJYpaC6FZ7btqub3UO67XIDjG5zTHgprpptqq9g6fbjWYwQi9NunOSabu 2AUuO2q69jxdlElApADFurvv/b5UXUxWo9c5hEXAMLM0utQ5A27FMnusVpjB3UigpsQ9 MRUxSYpgXhHI9s8iTat6kCLwDFgts6kPusw1Ze/UB1SoC2N5TTc68lhzHUX5pmih5rm+ 5MEGnsb7GpzgpE5kQUefcAPPKgHZ4iGmzmHeGSRaYJaTZs2MQt0bJlbqDDBYTZMXCpso oG1d+B8f9u/Xbe3xOMC/YYRKCynIfzeg1uEA2YxD15rvd7eJSxywikp2AlWsAKYrEaMj EkDA== X-Gm-Message-State: AOAM532v/IH62wsy/KkO57X3mqT/iFTymIXWLz7Grweg0Xg+5C0oY13T UEbcYMQW/4KAGr7UYeRWNmyPzNlZCTerdmZ2fbA= X-Google-Smtp-Source: ABdhPJxszvcfOXBhroUY7jPyXiCtidE2h+FxlkKVk4mqkChdjX4aQjH9b8xcZ/ptJIUByhKUCPsnM6d+FGdf7hSypGg= X-Received: by 2002:a05:6e02:eeb:: with SMTP id j11mr4691523ilk.295.1603531541020; Sat, 24 Oct 2020 02:25:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Romain Calascibetta Date: Sat, 24 Oct 2020 11:25:30 +0200 Message-ID: Subject: Re: How do I run hvt targets on qemu/kvm? To: Hans Ole Rafaelsen Cc: mirageos-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000e384e205b26747dd" --000000000000e384e205b26747dd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Hans Ole, First, thanks to trying to use MirageOS :) ! I'm not an expert about this part but I know the usual process to run a Solo5 MirageOS (without qemu). MirageOS (with OPAM) installs for you Solo5 bindings and binaries such as `solo5-hvt`. If you have the KVM permission (on GNU/Linux, you should be into the KVM group), you are able to launch a Solo5 MirageOS without root privileges. Let's take the `hello` unikernel available here: https://github.com/mirage/mirage-skeleton/tree/master/tutorial/hello To compile and use it, you should follow this process: ``` $ eval `opam env` $ mirage configure -t hvt $ make depends $ mirage build $ solo5-hvt -- hello.hvt ``` This is the most easy part where this unikernel does not need to be connected to the internet. For a unikernel which wants to communicate, you must have a TAP interface. At this step, the configuration depends on your infrastructure (if you have many IPs, only one, etc.). Just to still continue to explain, we can imagine a network bridge such as, into your /etc/network/interface, you have: ``` auto br1 iface br1 inet static address 10.0.0.0 broadcast 10.0.0.255 netmask 255.255.255.0 gateway 10.0.0.1 ``` Disclaimer: as I said, I'm not an expert about sysadmin (so, if someone can double-check that) but several HOW-TO exists on the internet to be able make a bridge network. Then, you need to create the TAP interface and plug it into the bridge: ``` # ip tuntap add mode tap tap100 # ip link set dev tap100 up # brctl addif br1 tap100 ``` Then, an unikernel such as https://github.com/mirage/mirage-skeleton/tree/master/applications/dns can be launched with: ``` $ solo5-hvt --net:service=3Dtap100 -- mir-dns.hvt --ipv4=3D10.0.0.2/24 --ipv4-gateway=3D10.0.0.1 ``` At this point, Hannes gives you some more information and, as I said, if we have some clues about your infrastructure, we will be able to give you a special help :) . Best Le sam. 24 oct. 2020 =C3=A0 08:34, Hans Ole Rafaelsen a =C3=A9crit : > Hi, > > When reading the MirageOS tutorials/documentation it seems like virtio > target has some limitations. E.g. only one network interface supported. > From the tutorials I get the impression that virtio will have limited > support in the future, while hvt seems to be better supported. > > Making virtio targets run on qemu/kvm is documented and quite > straightforward . But I can not find any way to make hvt targets run on > qemu/kvm. > > Is there some way to make hvt targets run on qemu/kvm? > > Regards, > > Hans Ole Rafaelsen > > --=20 Romain Calascibetta - http://din.osau.re/ --000000000000e384e205b26747dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Hans Ole,

First, th= anks to trying to use MirageOS :) ! I'm not an expert about this=C2=A0p= art but I know the usual process to run a Solo5 MirageOS (without qemu).
MirageOS (with OPAM) installs for you Solo5 bindings and binaries s= uch as `solo5-hvt`. If you have the KVM permission (on GNU/Linux, you shoul= d be into the KVM group),
you are able to launch a Solo5 MirageOS= without root privileges.

Let's take the `hell= o` unikernel available here:=C2=A0https://github.co= m/mirage/mirage-skeleton/tree/master/tutorial/hello
To compil= e and use it, you should follow this process:
```
$ eva= l `opam env`
$ mirage configure -t hvt
$ make depends
$ mirage build
$ solo5-hvt -- hello.hvt
```

This is the most easy part where this unikernel does= not need to be connected to the internet. For a unikernel which=C2=A0wants= to communicate, you must have a TAP interface.
At this step, the= configuration depends on your infrastructure (if you have many IPs, only o= ne, etc.). Just to still continue to explain, we can imagine a network brid= ge such as, into your /etc/network/interface, you have:
```
=
auto br1
iface br1 inet static
=C2=A0 address 10.0= .0.0
=C2=A0 broadcast 10.0.0.255
=C2=A0 netmask 255.255= .255.0
=C2=A0 gateway 10.0.0.1
```

=
Disclaimer: as I said, I'm not an expert about sysadmin (so, if so= meone can double-check that) but several HOW-TO exists on the internet to b= e able make a bridge network.

Then, you need to cr= eate the TAP interface and plug it into the bridge:
```
# ip tuntap add mode tap tap100
# ip link set dev tap100 up
# brctl addif br1 tap100
```

Then,= an unikernel such as=C2=A0https://github.com/mirage/mirage-skeleto= n/tree/master/applications/dns can be launched with:
```
$ solo5-hvt --net:service=3Dtap100 -- mir-dns.hvt --ipv4=3D10.0.0.2/24 --ipv4-gateway=3D10.0.0.1
``= `

At this point, Hannes gives you some more inform= ation and, as I said, if we have some clues about your infrastructure, we w= ill be able to give you a special help :) .

Best

Le=C2=A0sam. 24 oct. 2020 =C3=A0=C2=A008:34, Hans Ole Rafaelsen <hrafaelsen@gmail.com= > a =C3=A9crit=C2=A0:
Hi,

When rea= ding the MirageOS=20 tutorials/documentation it seems like virtio target has some=20 limitations. E.g. only one network interface supported. From the=20 tutorials I get the impression that virtio will have limited support in=20 the future, while hvt seems to be better supported.

Making virtio targets run on qemu/kvm is documented and quite straightforward . But I can not find any way to make hvt targets run on qemu/kvm.
=
Is there some way to make hvt targets run on qemu/kvm?
=

Regards,

Hans Ole Rafaelsen


--
Romain Calascibetta - ht= tp://din.osau.re/
--000000000000e384e205b26747dd-- From mirageos-devel-bounces@lists.xenproject.org Sat Oct 24 09:58:45 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 24 Oct 2020 09:58:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.11539.30615 (Exim 4.92) (envelope-from ) id 1kWGJr-00057o-2E; Sat, 24 Oct 2020 09:58:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 11539.30615; Sat, 24 Oct 2020 09:58:39 +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 1kWGJq-00057h-VY; Sat, 24 Oct 2020 09:58:38 +0000 Received: by outflank-mailman (input) for mailman id 11539; Sat, 24 Oct 2020 09:58:37 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kWGJp-00057c-NQ for mirageos-devel@lists.xenproject.org; Sat, 24 Oct 2020 09:58:37 +0000 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f56873a2-7e30-4286-8a06-ca002b802145; Sat, 24 Oct 2020 09:58:36 +0000 (UTC) Received: from nodbug.lucina.net (93-141-8-176.adsl.net.t-com.hr [93.141.8.176]) by smtp.lucina.net (Postfix) with ESMTPSA id A66E0122804 for ; Sat, 24 Oct 2020 11:58:35 +0200 (CEST) Received: by nodbug.lucina.net (Postfix, from userid 1000) id C134F2683D26; Sat, 24 Oct 2020 11:58:34 +0200 (CEST) Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kWGJp-00057c-NQ for mirageos-devel@lists.xenproject.org; Sat, 24 Oct 2020 09:58:37 +0000 X-Inumbo-ID: f56873a2-7e30-4286-8a06-ca002b802145 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f56873a2-7e30-4286-8a06-ca002b802145; Sat, 24 Oct 2020 09:58:36 +0000 (UTC) Received: from nodbug.lucina.net (93-141-8-176.adsl.net.t-com.hr [93.141.8.176]) by smtp.lucina.net (Postfix) with ESMTPSA id A66E0122804 for ; Sat, 24 Oct 2020 11:58:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201811; t=1603533515; bh=LDrsx0Ju9wZV7eh0e0lBAf1NEijCERw/rQOnLMqwNCY=; h=Date:From:To:Subject:References:In-Reply-To:From; b=D34PHBWfMRD4Oy9yyqXlOrrQi5rdH/UTJXfuen3iPR8LZYGQ+YR0HDISxeSthlhoG I6YR2bQAXOx4lbUqysfzgdFn8nDafaLHnBvWmth4WltWS52qy9IFF4KsVAs6bqLq8D 58gjkvUh1mR0HhRkknqxW0qqlBWtOCTDMbsGWO29dYnPbRAB4qjvF2LfaoO+cbhBcs JkmsmCp37W6denMfleOvPBI3Z2Sa5tzTZOnxe5rB8E8j7av2Lp7ajz8OnUX73C88UY uaRqHiCNFln+iZHEbIEgQYmDVBdx3Z3IXAxAfUvFhKMUsjiehHlpObuYTdcdfxOP4M 9kKrulRv3aUWA== Received: by nodbug.lucina.net (Postfix, from userid 1000) id C134F2683D26; Sat, 24 Oct 2020 11:58:34 +0200 (CEST) Date: Sat, 24 Oct 2020 11:58:34 +0200 From: Martin Lucina To: mirageos-devel@lists.xenproject.org Subject: Re: How do I run hvt targets on qemu/kvm? Message-ID: <20201024095834.GB16900@nodbug.lucina.net> Mail-Followup-To: Martin Lucina , mirageos-devel@lists.xenproject.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Hi Hans, others have already replied with instructions. Just to clarify the higher-level concepts: On Saturday, 24.10.2020 at 08:33, Hans Ole Rafaelsen wrote: > Hi, > > When reading the MirageOS tutorials/documentation it seems like virtio > target has some limitations. E.g. only one network interface supported. > From the tutorials I get the impression that virtio will have limited > support in the future, while hvt seems to be better supported. > > Making virtio targets run on qemu/kvm is documented and quite > straightforward . But I can not find any way to make hvt targets run on > qemu/kvm. QEMU/KVM, often referred to as just KVM has two parts to it. 1) The kernel-mode Type II hypervisor, KVM. 2) The user-mode process that manages the VM, provides/emulates devices and most of the "machine" part of the VM. This is known as the VMM (virtual machine manager) and is generally provided by QEMU, crosvm, or some cloud providers have an entirely custom, proprietary, codebase for it. The virtio target is designed to run on most "classic" hypervisors that provide 1) and 2), with 2) providing I/O devices based on the virtio specification [1]. The hvt target, on the other hand, is an extremely minimalst replacement for 2) above, provided by the Solo5 "tender" binary, solo5-hvt. In order to run that, you need access to either a) a bare metal server b) a cloud provider which implements nested virtualization in 1), thus effectively allowing you to run a nested instance of KVM and solo5-hvt on it. For more details, please see the Solo5 documentation [2]. > Is there some way to make hvt targets run on qemu/kvm? TL;DR no. :-) Cheers, Martin [1] https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html [2] https://github.com/solo5/solo5/#about-solo5 From mirageos-devel-bounces@lists.xenproject.org Sat Oct 24 21:11:57 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 24 Oct 2020 21:11:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.11660.30858 (Exim 4.92) (envelope-from ) id 1kWQpA-0005mb-TK; Sat, 24 Oct 2020 21:11:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 11660.30858; Sat, 24 Oct 2020 21:11:40 +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 1kWQpA-0005mU-Pz; Sat, 24 Oct 2020 21:11:40 +0000 Received: by outflank-mailman (input) for mailman id 11660; Sat, 24 Oct 2020 21:11:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kWQp9-0005mP-6q for mirageos-devel@lists.xenproject.org; Sat, 24 Oct 2020 21:11:39 +0000 Received: from mail-ed1-x533.google.com (unknown [2a00:1450:4864:20::533]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id cbc57016-2523-4f77-8f20-a2045b6beb30; Sat, 24 Oct 2020 21:11:38 +0000 (UTC) Received: by mail-ed1-x533.google.com with SMTP id a6so3885908edx.6 for ; Sat, 24 Oct 2020 14:11:38 -0700 (PDT) Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kWQp9-0005mP-6q for mirageos-devel@lists.xenproject.org; Sat, 24 Oct 2020 21:11:39 +0000 X-Inumbo-ID: cbc57016-2523-4f77-8f20-a2045b6beb30 Received: from mail-ed1-x533.google.com (unknown [2a00:1450:4864:20::533]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id cbc57016-2523-4f77-8f20-a2045b6beb30; Sat, 24 Oct 2020 21:11:38 +0000 (UTC) Received: by mail-ed1-x533.google.com with SMTP id a6so3885908edx.6 for ; Sat, 24 Oct 2020 14:11:38 -0700 (PDT) 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; bh=X2fWkXojwwU3O38YBLDEWVYEgBIWNoX5aJLIyI8aWRE=; b=FQkmSqILdCiJagBjLUdOgT4n3GW7ylGj2IiVhXbvRctL3dfDBf9XORYMkStfERBYJI 39sT+/wMsm6lD+ZFe3DR+9rIqb9M/khihLTfFOPO7bb+9IslvYokFtkDlHWQ6RSTPWdg y62JmZRoyIEoJNMNDCRTCkMjWteQ/qL0YB4HPxQzjaU+F92JBRvrwPS/IUQKyDJ3IHLJ c4cwg6Hg6v+49D0sBekcJ7JnUkqkKBh5X//kat0Eyhu2Rjsu47YxihfBf1rsh7hghNSs KZccxk+68wZei3Dg7Ab46Y6bBHlUfha+0Nt+iaeaClcnDCp4sB5TLNqObbOp5JlCOV+E gLow== 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; bh=X2fWkXojwwU3O38YBLDEWVYEgBIWNoX5aJLIyI8aWRE=; b=VLAm0VVo7urSGmYxoXzT1185TGZ5Xz6iVcxsPoErXzC74Iqlj39PnDo6YBZgQ5gn31 hyoWuiNfhkcLbqQ+k1Jr970yMGbZA3r9oKhEUesvgLiwwAu8sJCx3rXEhzF7z31ehI5P 7ennO6B/3S9QfFGD5s8fxnMrhjgRobaYFK9NBsUsdYNoO2pinmuS5ntamDrl10Ddxrwc x2Wj2LDHgt/FMLM5m5okshqLyCxR2vZhPv72Xr6Cx3jIKvRbxojL12Whn36pb/+LErSk Oq6shz+WKwmmOsjZavDobf975WF7SuMtzFskgJt92x/pmACnhH75kpLH66xoY0QJ7vZw tVpg== X-Gm-Message-State: AOAM532D9EX220SfLpv+LjPZFbieD2B4G0bGGPGhyJedSlkDXYxPm6aq nrhWpGOMPehDIkWk9N6rHpWSo53UT8v8XADyx3o= X-Google-Smtp-Source: ABdhPJwa6IwlcHY3Y7Q4+Y09ItEmA1L8UPlhsZy0xRi5MsGujH5Za497LRfkXK83vFloNsw0tjB1uAq6PHc+QA4do9E= X-Received: by 2002:a50:eb8c:: with SMTP id y12mr8367538edr.61.1603573897279; Sat, 24 Oct 2020 14:11:37 -0700 (PDT) MIME-Version: 1.0 References: <20201024095834.GB16900@nodbug.lucina.net> In-Reply-To: <20201024095834.GB16900@nodbug.lucina.net> From: Hans Ole Rafaelsen Date: Sat, 24 Oct 2020 23:11:25 +0200 Message-ID: Subject: Re: How do I run hvt targets on qemu/kvm? To: Martin Lucina , hannes@mehnert.org, romain.calascibetta@gmail.com, mirageos-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="00000000000084be4405b27124f2" --00000000000084be4405b27124f2 Content-Type: text/plain; charset="UTF-8" Hi Hannes, Romain and Martin, Thanks for your replays. I think I have a better understanding now. My goal is to get a small application running on a OpenStack qemu/kvm cloud. I have posted in a previous post about problems getting things going above solo5. So I had a little hope that hvt might be an option. But it seems like I'll need to try some more with libvirt as target. When creating images with solo5-virtio-image the raw image size becomes 1GB. This size is scrinked to almost the same size as the .virtio file when converted to Qcow2. Is there some way to set the raw image size when using the solo5-virtio-image command? Regards, Hans Ole On Sat, Oct 24, 2020 at 11:59 AM Martin Lucina wrote: > Hi Hans, > > others have already replied with instructions. Just to clarify the > higher-level concepts: > > On Saturday, 24.10.2020 at 08:33, Hans Ole Rafaelsen wrote: > > Hi, > > > > When reading the MirageOS tutorials/documentation it seems like virtio > > target has some limitations. E.g. only one network interface supported. > > From the tutorials I get the impression that virtio will have limited > > support in the future, while hvt seems to be better supported. > > > > Making virtio targets run on qemu/kvm is documented and quite > > straightforward . But I can not find any way to make hvt targets run on > > qemu/kvm. > > QEMU/KVM, often referred to as just KVM has two parts to it. > > 1) The kernel-mode Type II hypervisor, KVM. > 2) The user-mode process that manages the VM, provides/emulates devices and > most of the "machine" part of the VM. This is known as the VMM (virtual > machine manager) and is generally provided by QEMU, crosvm, or some cloud > providers have an entirely custom, proprietary, codebase for it. > > The virtio target is designed to run on most "classic" hypervisors that > provide 1) and 2), with 2) providing I/O devices based on the virtio > specification [1]. > > The hvt target, on the other hand, is an extremely minimalst replacement > for 2) above, provided by the Solo5 "tender" binary, solo5-hvt. In order to > run that, you need access to either > > a) a bare metal server > b) a cloud provider which implements nested virtualization in 1), thus > effectively allowing you to run a nested instance of KVM and solo5-hvt on > it. > > For more details, please see the Solo5 documentation [2]. > > > Is there some way to make hvt targets run on qemu/kvm? > > TL;DR no. :-) > > Cheers, > > Martin > > [1] > > https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html > > [2] https://github.com/solo5/solo5/#about-solo5 > > > --00000000000084be4405b27124f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Hannes, Romain and Martin,

Thanks for your replays. I think I have a better understanding now.
=

My goal is to get a small application running on a Open= Stack qemu/kvm cloud. I have posted in a previous post about problems getti= ng things going above solo5. So I had a little hope that hvt might be an op= tion. But it seems like I'll need to try some more with libvirt as targ= et.

When creating images with solo5-virtio-image t= he raw image size becomes 1GB. This size is scrinked to almost the same siz= e as the .virtio file when converted to Qcow2. Is there some way to set the= raw image size when using the solo5-virtio-image command?

<= /div>
Regards,

Hans Ole

On Sat, Oct 2= 4, 2020 at 11:59 AM Martin Lucina <= martin@lucina.net> wrote:
Hi Hans,

others have already replied with instructions. Just to clarify the
higher-level concepts:

On Saturday, 24.10.2020 at=C2=A008:33, Hans Ole Rafaelsen wrote:
>=C2=A0 Hi,
>
> When reading the MirageOS tutorials/documentation it seems like virtio=
> target has some limitations. E.g. only one network interface supported= .
> From the tutorials I get the impression that virtio will have limited<= br> > support in the future, while hvt seems to be better supported.
>
> Making virtio targets run on qemu/kvm is documented and quite
> straightforward . But I can not find any way to make hvt targets run o= n
> qemu/kvm.

QEMU/KVM, often referred to as just KVM has two parts to it.

1) The kernel-mode Type II hypervisor, KVM.
2) The user-mode process that manages the VM, provides/emulates devices and=
most of the "machine" part of the VM. This is known as the VMM (v= irtual
machine manager) and is generally provided by QEMU, crosvm, or some cloud providers have an entirely custom, proprietary, codebase for it.

The virtio target is designed to run on most "classic" hypervisor= s that
provide 1) and 2), with 2) providing I/O devices based on the virtio
specification [1].

The hvt target, on the other hand, is an extremely minimalst replacement for 2) above, provided by the Solo5 "tender" binary, solo5-hvt. I= n order to
run that, you need access to either

a) a bare metal server
b) a cloud provider which implements nested virtualization in 1), thus
effectively allowing you to run a nested instance of KVM and solo5-hvt on it.

For more details, please see the Solo5 documentation [2].

> Is there some way to make hvt targets run on qemu/kvm?

TL;DR no. :-)

Cheers,

Martin

[1]
https://docs.oasis-op= en.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html

[2] https://github.com/solo5/solo5/#about-solo5


--00000000000084be4405b27124f2-- From mirageos-devel-bounces@lists.xenproject.org Sun Oct 25 12:38:16 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 25 Oct 2020 12:38:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.11868.31243 (Exim 4.92) (envelope-from ) id 1kWfHc-0008IQ-2F; Sun, 25 Oct 2020 12:38:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 11868.31243; Sun, 25 Oct 2020 12:38:00 +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 1kWfHb-0008IJ-VH; Sun, 25 Oct 2020 12:37:59 +0000 Received: by outflank-mailman (input) for mailman id 11868; Sun, 25 Oct 2020 12:37:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kWfHa-0008I5-CM for mirageos-devel@lists.xenproject.org; Sun, 25 Oct 2020 12:37:58 +0000 Received: from mail-ed1-x52d.google.com (unknown [2a00:1450:4864:20::52d]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8523c37f-1370-42cd-997e-c309dd8319ba; Sun, 25 Oct 2020 12:37:56 +0000 (UTC) Received: by mail-ed1-x52d.google.com with SMTP id l24so6594622edj.8 for ; Sun, 25 Oct 2020 05:37:56 -0700 (PDT) Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kWfHa-0008I5-CM for mirageos-devel@lists.xenproject.org; Sun, 25 Oct 2020 12:37:58 +0000 X-Inumbo-ID: 8523c37f-1370-42cd-997e-c309dd8319ba Received: from mail-ed1-x52d.google.com (unknown [2a00:1450:4864:20::52d]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8523c37f-1370-42cd-997e-c309dd8319ba; Sun, 25 Oct 2020 12:37:56 +0000 (UTC) Received: by mail-ed1-x52d.google.com with SMTP id l24so6594622edj.8 for ; Sun, 25 Oct 2020 05:37:56 -0700 (PDT) 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; bh=Sj17eD2Lpjk4ZvMz02nF6YaYgtrumF9BxmloDpBpKG8=; b=S/97oyYIofEO91OhwkXkJ6HIPyAXXLOts4oc4U6S9BThq6Z6zd0X6YF7mV3iGBh2ZX l/ZZ5PsSLzPfpGQ3s6k5FCfaZUqc0TaatOSVxSD7ZSPMy4iGQMXcHGchKTBymysm5H5P 5ypWs7aKRtS5rChZY/3a7qfE6YLX5KquvUarQtNnMsekkPHfuz6JUPx5zecNFLs92gvB Je8Fk5q/0teCzg6IFPgLGFUDrf46av6bAii1L9nESa+oakaGgXam+OAEDxeTBqOD4TvC pFyFbWi/I+Qj/E9gFdIu7NIIRjMJy7nHVU3x8ktxuTdWMNG2ievQvh0K1i34w+JMZtLA Ym6A== 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; bh=Sj17eD2Lpjk4ZvMz02nF6YaYgtrumF9BxmloDpBpKG8=; b=c4mXKdi2KPmtxQVn+7Y5EN1OEMDEZsI+YWtODcT+xO/sZLRoTVHWP/6o1MkIp6TI2K v6YuhvpJWx7aNeFiNMyEcAWUaw614mYvjHwf/5iZIMIOVamfCuTn6UR0AHGERntruxU+ e1Sz1yunIK/h91Tp7fV5YQzWS3TrO51IxyDi8wvG9TuEmWhnR+g2A+ka3fdSkN9BJVpC REMmcqVOnE4ZWd95qOVZVPU17AWGffefYW01eyTbjCYkjaxJbwIcIaiNr6NczmBGQ/s4 7KTJh18/5I+luaO0zRs1t4YGWYRM9mNBEVKwZax2EGOZ5pPPvmZ7o1D//F2hA+pxcfUW W3kw== X-Gm-Message-State: AOAM531UiQ4+Ke4yrfxBVjZn8dSovuzo5KywZdeASK0/jxPLEpmRFkzz nZxOQgzJE+kxomKIPRjzZNZihejHWvbtYe6ewU7GErTDGK0= X-Google-Smtp-Source: ABdhPJyOpIIeSrFmTyenoTJKr6krV2uQKpuXqb0ddF2V6YhjDP/jN4hR2dMGA3npXWMKHD4JN5XpcUUdqtXNYMkBE6M= X-Received: by 2002:aa7:dcd6:: with SMTP id w22mr11118534edu.378.1603629475253; Sun, 25 Oct 2020 05:37:55 -0700 (PDT) MIME-Version: 1.0 References: <20201016121547.GA19073@nodbug.lucina.net> In-Reply-To: From: Hans Ole Rafaelsen Date: Sun, 25 Oct 2020 13:37:43 +0100 Message-ID: Subject: Re: MirageOS on OpenStack problem To: mirageos-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="0000000000003953c205b27e15e5" --0000000000003953c205b27e15e5 Content-Type: text/plain; charset="UTF-8" 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 The VM uses 100% CPU and needs to be killed hard (-KILL). The system is: $ uname -a Linux hans-Latitude-E7470 4.15.0-118-generic #119-Ubuntu SMP Tue Sep 8 12:30:01 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux $ cat /etc/issue Ubuntu 18.04.5 LTS \n \l 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? Regards, Hans Ole On Sat, Oct 17, 2020 at 8:04 PM Hans Ole Rafaelsen wrote: > Hi Martin, > > Thanks for your answer. > > On Fri, Oct 16, 2020 at 2:15 PM Martin Lucina wrote: > >> Hi Hans, >> >> On Sunday, 11.10.2020 at 19:55, Hans Ole Rafaelsen wrote: >> > Hi, >> > >> > I'm trying to run some of the tutorial examples on OpenStack. This is a >> > "Nokia AirFrame Cloud Infrastructure" with "OpenStack Compute version >> > 17.0.7-1" >> >> Any idea what QEMU version that uses internally? >> > I have asked the provider. I'll let you know if I get a reply. > > >> > >> > I have built a virtio target and created a qcow2 image. >> > >> > When running this on OpenStack it seems to start the Solo5 execution >> > environment, but the MirageOS application does not seem to start. The >> log >> > only show: >> >> Which example, specifically? >> > First the network example, and later the "hello world" example, taken from > https://github.com/mirage/mirage-skeleton > > >> > SYSLINUX 6.03 20171017 Copyright (C) 1994-2014 H. Peter Anvin et al >> > Loading unikernel.bin... ok >> > | ___| >> > __| _ \ | _ \ __ \ >> > \__ \ ( | | ( | ) | >> > ____/\___/ _|\___/____/ >> > Solo5: Bindings version v0.6.6 >> > Solo5: Memory map: 1024 MB addressable: >> > Solo5: reserved @ (0x0 - 0xfffff) >> > Solo5: text @ (0x100000 - 0x47dfff) >> > Solo5: rodata @ (0x47e000 - 0x519fff) >> > Solo5: data @ (0x51a000 - 0x74afff) >> > Solo5: heap >= 0x74b000 < stack < 0x40000000 >> > Solo5: Clock source: KVM paravirtualized clock >> > Solo5: PCI:00:03: virtio-net device, base=0xc060, irq=11 >> > Solo5: PCI:00:03: configured, mac=fa:16:3e:a6:51:b7, features=0x48bf81a6 >> > Solo5: PCI:00:04: virtio-block device, base=0xc000, irq=11 >> > Solo5: PCI:00:04: configured, capacity=125829120 sectors, >> features=0x79000e54 >> > >> > Not sure if it is a problem with getting the log output from the >> > application or if it is not starting at all. The cloud infrastructure >> says >> > the VM is active, but it does not show the actual resource usage of the >> VM, >> > so it is hard to say what is going on. >> > For network applications it does not respond to ping, so it seems like >> it >> > is not running. >> >> Try adding "--logs=*:debug" to the kernel command line. >> > I tried adding it during the "mirage configure" step. On the local qemu VM > I get additional debugging info, but on the OpenStack cloud I get the same > result. No logs from the application itself. > > >> >> > >> > The qcow2 image runs fine on a local (Ubuntu 18.04 host) qemu/kvm VM >> and I >> > have no problem running other qcow2 images (Ubuntu) on the OpenStack >> cloud. >> > >> > Is there some limitation on the images created with mirage/solo5 that >> > prevents them from running on the OpenStack platform? >> >> I suspect no one's tried on OpenStack. Also, be aware that the virtio >> target is somewhat limited; all the exciting stuff is going on in the >> other >> Solo5-based targets. >> >> I tried another post about that on the mailing list, but it seems like it > has got stuck. (This post took 2 days before showing up on the list.) > > Is there some way to make a hvt target to run on qemu/kvm? > > -- > Hans Ole > > -mato >> >> > >> > Any tips on how to investigate this problem? >> > >> > Regards, >> > >> > Hans Ole Rafaelsen >> > --0000000000003953c205b27e15e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I have been investigatin= g some more, and I seem to be a 'virtio-block device' problem. On t= he OpenStack cloud this device is reported when Solo5 boots, but not on my = local installation.

I changed from IDE (default) t= o virtio as a drive on my local installation, and that gives the same behav= iour as on the cloud. So the behaviour can be shown with these two differen= t examples.

Using a IDE drive for the image:
=
$ qemu-system-x86_64 -cpu Westmere -m 128 -nodefaults -no-acpi -displa= y none -serial stdio -device virtio-net,netdev=3Dn0 -netdev tap,id=3Dn0,ifn= ame=3Dtap100,script=3Dno,downscript=3Dno -device isa-debug-exit -device lsi= ,id=3Dscsi0,bus=3Dpci.0,addr=3D0x9 \
-drive file=3D/home/han= s/src/5g/mirage/repository.qcow2,format=3Dqcow2,if=3Dnone,id=3Ddrive-ide0-0= -0 -device ide-hd,bus=3Dide.0,unit=3D0,drive=3Ddrive-ide0-0-0,id=3Dide0-0-0= ,bootindex=3D1

SYSLINUX 6.03 20171017 Copyright (C) 1994-2014 H. Pet= er 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) |
____/\___/ _= |\___/____/
Solo5: Bindings version v0.6.7
Solo5: Memory map: 128 MB = addressable:
Solo5: =C2=A0 reserved @ (0x0 - 0xfffff)
Solo5: =C2=A0 = =C2=A0 =C2=A0 text @ (0x100000 - 0x481fff)
Solo5: =C2=A0 =C2=A0 rodata @= (0x482000 - 0x51dfff)
Solo5: =C2=A0 =C2=A0 =C2=A0 data @ (0x51e000 - 0x= 74efff)
Solo5: =C2=A0 =C2=A0 =C2=A0 heap >=3D 0x74f000 < stack <= ; 0x8000000
Solo5: Clock source: TSC, frequency estimate is 2808856460 H= z
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
S= olo5: Application acquired 'service' as network device
2020-10-2= 5 12:16:34 -00:00: INF [netif] Plugging into service with mac 52:54:00:12:3= 4:56 mtu 1500
2020-10-25 12:16:34 -00:00: INF [ethernet] Connected Ether= net interface 52:54:00:12:34:56

Using virtio d= rive for the image:
$ qemu-system-x86_64 -cpu Westmere -m 128 -no= defaults -no-acpi -display none -serial stdio -device virtio-net,netdev=3Dn= 0 -netdev tap,id=3Dn0,ifname=3Dtap100,script=3Dno,downscript=3Dno -device i= sa-debug-exit \
-drive file=3D/home/hans/src/hermod-5g/mirage/rep= ository.qcow2,format=3Dqcow2,if=3Dnone,id=3Ddrive-virtio-disk0 -device virt= io-blk-pci,scsi=3Doff,bus=3Dpci.0,addr=3D0xa,drive=3Ddrive-virtio-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) |=
____/\___/ _|\___/____/
Solo5: Bindings version v0.6.7
Solo5: Mem= ory map: 127 MB addressable:
Solo5: =C2=A0 reserved @ (0x0 - 0xfffff)Solo5: =C2=A0 =C2=A0 =C2=A0 text @ (0x100000 - 0x481fff)
Solo5: =C2=A0 = =C2=A0 rodata @ (0x482000 - 0x51dfff)
Solo5: =C2=A0 =C2=A0 =C2=A0 data @= (0x51e000 - 0x74efff)
Solo5: =C2=A0 =C2=A0 =C2=A0 heap >=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=3D= 0x79bfffe7
Solo5: PCI:00:0a: virtio-block device, base=3D0xc000, irq=3D1= 0
Solo5: PCI:00:0a: configured, capacity=3D2097152 sectors, features=3D0= x79000e54
qemu-system-x86_64: virtio: zero sized buffers are not allowed=

The VM uses 100% CPU and needs to be killed hard = (-KILL).

The system is:
$ uname -a
Li= nux hans-Latitude-E7470 4.15.0-118-generic #119-Ubuntu SMP Tue Sep 8 12:30:= 01 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/issue
Ubuntu 18= .04.5 LTS \n \l

Is the problem that I need to = set up handlers etc. to handle a virtio block device in the MirageOS applic= ation? I can't find anything about this in the documentation. Or might = it be a bug in Solo5/MirageOS?

Regards,
=
Hans Ole


On Sat, Oct 17, 2020 at 8:0= 4 PM Hans Ole Rafaelsen <hrafael= sen@gmail.com> wrote:
Hi Martin,

= Thanks for your answer.

On Fri, Oct 16, 2020 at 2:15 PM Martin Lu= cina <martin@luci= na.net> wrote:
Hi Hans,

On Sunday, 11.10.2020 at=C2=A019:55, Hans Ole Rafaelsen wrote:
> Hi,
>
> I'm trying to run some of the tutorial examples on OpenStack. This= is a
> "Nokia AirFrame Cloud Infrastructure" with "OpenStack C= ompute version
> 17.0.7-1"

Any idea what QEMU version that uses internally?
I hav= e asked the provider. I'll let you know if I get a reply.

>
> I have built a virtio target and created a qcow2 image.
>
> When running this on OpenStack it seems to start the Solo5 execution > environment, but the MirageOS application does not seem to start. The = log
> only show:

Which example, specifically?
First the network example= , and later the "hello world" example, taken from https://github.com= /mirage/mirage-skeleton


> 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.6
> Solo5: Memory map: 1024 MB addressable:
> Solo5:=C2=A0 =C2=A0reserved @ (0x0 - 0xfffff)
> Solo5:=C2=A0 =C2=A0 =C2=A0 =C2=A0text @ (0x100000 - 0x47dfff)
> Solo5:=C2=A0 =C2=A0 =C2=A0rodata @ (0x47e000 - 0x519fff)
> Solo5:=C2=A0 =C2=A0 =C2=A0 =C2=A0data @ (0x51a000 - 0x74afff)
> Solo5:=C2=A0 =C2=A0 =C2=A0 =C2=A0heap >=3D 0x74b000 < stack <= 0x40000000
> Solo5: Clock source: KVM paravirtualized clock
> Solo5: PCI:00:03: virtio-net device, base=3D0xc060, irq=3D11
> Solo5: PCI:00:03: configured, mac=3Dfa:16:3e:a6:51:b7, features=3D0x48= bf81a6
> Solo5: PCI:00:04: virtio-block device, base=3D0xc000, irq=3D11
> Solo5: PCI:00:04: configured, capacity=3D125829120 sectors, features= =3D0x79000e54
>
> Not sure if it is a problem with getting the log output from the
> application or if it is not starting at all. The cloud infrastructure = says
> the VM is active, but it does not show the actual resource usage of th= e VM,
> so it is hard to say what is going on.
> For network applications it does not respond to ping, so it seems like= it
> is not running.

Try adding "--logs=3D*:debug" to the kernel command line.
I tried adding it during the "mirage configure" ste= p. On the local qemu VM I get additional debugging info, but on the OpenSta= ck cloud I get the same result. No logs from the application itself.
=C2=A0

>
> The qcow2 image runs fine on a local (Ubuntu 18.04 host) qemu/kvm VM a= nd I
> have no problem running other qcow2 images (Ubuntu) on the OpenStack c= loud.
>
> Is there some limitation on the images created with mirage/solo5 that<= br> > prevents them from running on the OpenStack platform?

I suspect no one's tried on OpenStack. Also, be aware that the virtio target is somewhat limited; all the exciting stuff is going on in the other=
Solo5-based targets.

I tried another post about that on the mailing list, = but it seems like it has got stuck. (This post took 2 days before showing u= p on the list.)=C2=A0

Is there some way to make a = hvt target to run on qemu/kvm?

--
H= ans Ole

-mato

>
> Any tips on how to investigate this problem?
>
> Regards,
>
> Hans Ole Rafaelsen
--0000000000003953c205b27e15e5-- From mirageos-devel-bounces@lists.xenproject.org Mon Oct 26 10:33:22 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 26 Oct 2020 10:33:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.12204.31957 (Exim 4.92) (envelope-from ) id 1kWzoH-00068L-5k; Mon, 26 Oct 2020 10:33:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 12204.31957; Mon, 26 Oct 2020 10:33:05 +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 1kWzoH-00068E-2N; Mon, 26 Oct 2020 10:33:05 +0000 Received: by outflank-mailman (input) for mailman id 12204; Mon, 26 Oct 2020 10:33:03 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kWzoF-000689-Ge for mirageos-devel@lists.xenproject.org; Mon, 26 Oct 2020 10:33:03 +0000 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5bba3639-2744-419a-b09f-be13023467a3; Mon, 26 Oct 2020 10:33:02 +0000 (UTC) Received: from nodbug.lucina.net (93-137-75-189.adsl.net.t-com.hr [93.137.75.189]) by smtp.lucina.net (Postfix) with ESMTPSA id 63C4B122804 for ; Mon, 26 Oct 2020 11:33:01 +0100 (CET) Received: by nodbug.lucina.net (Postfix, from userid 1000) id 5DCE82683D52; Mon, 26 Oct 2020 11:33:00 +0100 (CET) Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kWzoF-000689-Ge for mirageos-devel@lists.xenproject.org; Mon, 26 Oct 2020 10:33:03 +0000 X-Inumbo-ID: 5bba3639-2744-419a-b09f-be13023467a3 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5bba3639-2744-419a-b09f-be13023467a3; Mon, 26 Oct 2020 10:33:02 +0000 (UTC) Received: from nodbug.lucina.net (93-137-75-189.adsl.net.t-com.hr [93.137.75.189]) by smtp.lucina.net (Postfix) with ESMTPSA id 63C4B122804 for ; Mon, 26 Oct 2020 11:33:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201811; t=1603708381; bh=U7iGWJiNzfTGpGgIrpNQ+W0D13RiupCEhepfuAEb45Y=; h=Date:From:To:Subject:References:In-Reply-To:From; b=HhmS2Ik54Q0Ny0POdYroP4rXphXW6Am34Q7/KrVf3YfSGnredfCL0jrJYAtPVA1oT Ins7RgQD1QDBmdqoSiuZ9dU/TfEm7SHq0CI2kx067Ju03ezJ8DJLHy42bVDDHndkZX DR/mbi/AeiyFFtCTgAGJoQQys3P39qvkdGtEqd/AlGsPWHwsr3JtEt5rNAmyqlxLhO qIFcTASIpAZrXvdPAmlsu4EuyFa6YoUIQ1TDNDrFZtMizHPpjbpHlRA5086Ksx8v8F BmnGsSw4O52kxx6C5aVfJ9hz5mr1zwNiUEMjgG4nPUZHdmXls+cq4IGnrTMFXxBSy0 T/kFTrSQwyHBg== Received: by nodbug.lucina.net (Postfix, from userid 1000) id 5DCE82683D52; Mon, 26 Oct 2020 11:33:00 +0100 (CET) Date: Mon, 26 Oct 2020 11:33:00 +0100 From: Martin Lucina To: mirageos-devel@lists.xenproject.org Subject: Re: How do I run hvt targets on qemu/kvm? Message-ID: <20201026103300.GA11343@nodbug.lucina.net> Mail-Followup-To: Martin Lucina , mirageos-devel@lists.xenproject.org References: <20201024095834.GB16900@nodbug.lucina.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Hi Hans, On Saturday, 24.10.2020 at 23:11, Hans Ole Rafaelsen wrote: > Hi Hannes, Romain and Martin, > > Thanks for your replays. I think I have a better understanding now. > > My goal is to get a small application running on a OpenStack qemu/kvm > cloud. I have posted in a previous post about problems getting things going > above solo5. So I had a little hope that hvt might be an option. But it > seems like I'll need to try some more with libvirt as target. Libvirt is just an abstraction layer on top of some KVM/QEMU instance. Not sure what you mean here. > When creating images with solo5-virtio-image the raw image size becomes > 1GB. This size is scrinked to almost the same size as the .virtio file when The image size is somewhat arbitrary, and it's actually a sparse file on a local filesystem, or at least should be. > converted to Qcow2. Is there some way to set the raw image size when using > the solo5-virtio-image command? Not at the moment, but you can edit $SIZE, see the comments in solo5-virtio-mkimage.sh. It'd be trivial to add both a) support for producing QCOW2 directly, and b) an option to specify the image size. Cheers, Martin > From mirageos-devel-bounces@lists.xenproject.org Mon Oct 26 10:37:51 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 26 Oct 2020 10:37:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.12206.31962 (Exim 4.92) (envelope-from ) id 1kWzss-0006E2-Ju; Mon, 26 Oct 2020 10:37:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 12206.31962; Mon, 26 Oct 2020 10:37:50 +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 1kWzss-0006Dv-GA; Mon, 26 Oct 2020 10:37:50 +0000 Received: by outflank-mailman (input) for mailman id 12206; Mon, 26 Oct 2020 10:37:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kWzsr-0006Dq-65 for mirageos-devel@lists.xenproject.org; Mon, 26 Oct 2020 10:37:49 +0000 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6ef79739-e5ae-42f7-8b38-3e0e761ca900; Mon, 26 Oct 2020 10:37:48 +0000 (UTC) Received: from nodbug.lucina.net (93-137-75-189.adsl.net.t-com.hr [93.137.75.189]) by smtp.lucina.net (Postfix) with ESMTPSA id 57525122804; Mon, 26 Oct 2020 11:37:47 +0100 (CET) Received: by nodbug.lucina.net (Postfix, from userid 1000) id 9EC2A2683D52; Mon, 26 Oct 2020 11:37:46 +0100 (CET) Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kWzsr-0006Dq-65 for mirageos-devel@lists.xenproject.org; Mon, 26 Oct 2020 10:37:49 +0000 X-Inumbo-ID: 6ef79739-e5ae-42f7-8b38-3e0e761ca900 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6ef79739-e5ae-42f7-8b38-3e0e761ca900; Mon, 26 Oct 2020 10:37:48 +0000 (UTC) Received: from nodbug.lucina.net (93-137-75-189.adsl.net.t-com.hr [93.137.75.189]) by smtp.lucina.net (Postfix) with ESMTPSA id 57525122804; Mon, 26 Oct 2020 11:37:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201811; t=1603708667; bh=392VZiDHrZsBDW8DBKzppHmI3++y0K7/SKl1nABHmbc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pbGp1RC1SlLJ9cvo4PXsgTHSARTxUVBOl+TJcC5fgoFNhBtDp+45lNLpTC3w8VoVb DdGfoR6I8Jqb5DLnC0X12yHs90AilSti/cUBrG0iSZOsO8w82p8wJlXGfuJHJJVAWE dD5fsSBpgshgSBqIalOeJVZgW0cxp9nFFDnrOBCPDgxvVAA4PjxNwv8Ty+vp1QagE4 FlB/S7P6I7GrCwArf0IZjmuJggW0bPJ8n2F07JbRo949ypBuAgmwC8RaAG8qfEZ5/k /Q26XKZZ3uXSpyE5JG0DthYnYNgjFX9A+wC3gCY4SjpB0m6h3kiOs29V20yVsnU5iW h3WaT3FDRwP1Q== Received: by nodbug.lucina.net (Postfix, from userid 1000) id 9EC2A2683D52; Mon, 26 Oct 2020 11:37:46 +0100 (CET) Date: Mon, 26 Oct 2020 11:37:46 +0100 From: Martin Lucina To: mirageos-devel@lists.xenproject.org Cc: Ricardo Koller Subject: Re: MirageOS on OpenStack problem Message-ID: <20201026103746.GB11343@nodbug.lucina.net> Mail-Followup-To: Martin Lucina , mirageos-devel@lists.xenproject.org, Ricardo Koller References: <20201016121547.GA19073@nodbug.lucina.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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 From mirageos-devel-bounces@lists.xenproject.org Mon Oct 26 10:43:48 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 26 Oct 2020 10:43:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.12209.31979 (Exim 4.92) (envelope-from ) id 1kWzyV-00078e-Gi; Mon, 26 Oct 2020 10:43:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 12209.31979; Mon, 26 Oct 2020 10:43:39 +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 1kWzyV-00078X-DG; Mon, 26 Oct 2020 10:43:39 +0000 Received: by outflank-mailman (input) for mailman id 12209; Mon, 26 Oct 2020 10:43:38 +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 1kWzyU-00078F-94 for mirageos-devel@lists.xenproject.org; Mon, 26 Oct 2020 10:43:38 +0000 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id bccab56d-6f27-4866-b735-9ae1847972f2; Mon, 26 Oct 2020 10:43:37 +0000 (UTC) Received: from nodbug.lucina.net (93-137-75-189.adsl.net.t-com.hr [93.137.75.189]) by smtp.lucina.net (Postfix) with ESMTPSA id 57900122804; Mon, 26 Oct 2020 11:43:36 +0100 (CET) Received: by nodbug.lucina.net (Postfix, from userid 1000) id A206A2683D52; Mon, 26 Oct 2020 11:43:35 +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 1kWzyU-00078F-94 for mirageos-devel@lists.xenproject.org; Mon, 26 Oct 2020 10:43:38 +0000 X-Inumbo-ID: bccab56d-6f27-4866-b735-9ae1847972f2 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id bccab56d-6f27-4866-b735-9ae1847972f2; Mon, 26 Oct 2020 10:43:37 +0000 (UTC) Received: from nodbug.lucina.net (93-137-75-189.adsl.net.t-com.hr [93.137.75.189]) by smtp.lucina.net (Postfix) with ESMTPSA id 57900122804; Mon, 26 Oct 2020 11:43:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201811; t=1603709016; bh=jwuXUwGmOVit4MYR2iROQ/ygG/+uwU1UY3Z4fh0h7tY=; h=Date:From:To:Subject:References:In-Reply-To:From; b=HPvS+utHjzLvYLK83MMF6NwT6SFTNIFWeCHQyxwiCT8sh3M5J8PgktCGtbOiJnOyZ kunhF2eJnWX+g/cG0+NYvrPBw4olHjL+USAM2LSYQNEQhJQExA21iT5cJi/PPBc0Fg GF/cb0RDnRRQvR1361YoBivpcoN1VMlh6tbzt0gldo/grpMgdFheLPkzwQcU8Y2qtG 6fYO4taQyoSUeQK1teigrSZUaCzfV6opLPWxHr1VoeoIPDWsYoT6P7sA3CzQ0cwUg7 t40s5sxb/SmyqAF7ll39xhREsw20gLXuq7fwDsGNQcMaxaF7Fp3SnumbWTnUdYDETs 1byZKQl0/2HeA== Received: by nodbug.lucina.net (Postfix, from userid 1000) id A206A2683D52; Mon, 26 Oct 2020 11:43:35 +0100 (CET) Date: Mon, 26 Oct 2020 11:43:35 +0100 From: Martin Lucina To: mirageos-devel@lists.xenproject.org, Ricardo Koller Subject: Re: MirageOS on OpenStack problem Message-ID: <20201026104335.GC11343@nodbug.lucina.net> Mail-Followup-To: Martin Lucina , mirageos-devel@lists.xenproject.org, Ricardo Koller References: <20201016121547.GA19073@nodbug.lucina.net> <20201026103746.GB11343@nodbug.lucina.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20201026103746.GB11343@nodbug.lucina.net> User-Agent: Mutt/1.10.1 (2018-07-13) (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 > From mirageos-devel-bounces@lists.xenproject.org Mon Oct 26 10:48:01 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 26 Oct 2020 10:48:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.12219.31991 (Exim 4.92) (envelope-from ) id 1kX02j-0007M9-02; Mon, 26 Oct 2020 10:48:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 12219.31991; Mon, 26 Oct 2020 10:48:00 +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 1kX02i-0007M2-TO; Mon, 26 Oct 2020 10:48:00 +0000 Received: by outflank-mailman (input) for mailman id 12219; Mon, 26 Oct 2020 10:48:00 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kX02i-0007Lu-0t for mirageos-devel@lists.xenproject.org; Mon, 26 Oct 2020 10:48:00 +0000 Received: from mail-ej1-x62a.google.com (unknown [2a00:1450:4864:20::62a]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d4b50aaf-77da-4de3-8b38-15bcd4a294bb; Mon, 26 Oct 2020 10:47:58 +0000 (UTC) Received: by mail-ej1-x62a.google.com with SMTP id p9so12683386eji.4 for ; Mon, 26 Oct 2020 03:47:58 -0700 (PDT) Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kX02i-0007Lu-0t for mirageos-devel@lists.xenproject.org; Mon, 26 Oct 2020 10:48:00 +0000 X-Inumbo-ID: d4b50aaf-77da-4de3-8b38-15bcd4a294bb Received: from mail-ej1-x62a.google.com (unknown [2a00:1450:4864:20::62a]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d4b50aaf-77da-4de3-8b38-15bcd4a294bb; Mon, 26 Oct 2020 10:47:58 +0000 (UTC) Received: by mail-ej1-x62a.google.com with SMTP id p9so12683386eji.4 for ; Mon, 26 Oct 2020 03:47:58 -0700 (PDT) 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; bh=vXiYr9mlHmbwWzfJtLwIlQ9VrFsSm7B+qWE9wNgIVZ0=; b=MnZSijjCxrdXCPw5T+ux3FQH+BZ12Td/7ewP8/0VH0qi5BNqMHQl53tCLAooTmHsdV Isy/ZyCQsQrLH8tC1/Ofhkf3nfS90xIV9Rpm75jyVS/2THtpKwi+7wVokl9G2P4+UBzQ hZ30WnOMVfCC7eIZfGTLIjT7mjN8JvdZcEPlfAJCfeSpzb9EtKHJwdw6PkrtJfHbz5dC EEp8shfZR1295RoRQ+M04jaAu+SfDkZNDNRlUqJKkU8PRxzi3ic99Q2lCkbS2VRwu6bC dOKqJK+1cNc1Ze2cazLEA7mpjAc9Xg4kNSECRj3VRp75quxHIInRY7YRTgNxTfcHu2at B4NA== 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; bh=vXiYr9mlHmbwWzfJtLwIlQ9VrFsSm7B+qWE9wNgIVZ0=; b=EMws1cHmYh8/5kUisR8ymUP7Yn5qJkwGy+Yiz95VR0v6OuWAVp8KaQmoKbrfoJgkps owDAak2s8W4Oj3mUHkCqg1a04jJHjaQeMMAGTpLh3hx/LxtKlin+iXpKnZVYyPHan5m3 H/iNYRzrOFr9zYEsjCRItjT7Owlmay8Cyf12xnkDvTgtbWjf4nfm7/2WKkuk7IAhhdRt IaLgqgtns9eI+U4l5SeGDX4hICHtSoTsa8gz1uqfCyim6VUQpKRoPG2sNclJKMVVpoqG LwuvN1jwBp9LAeeIEq5MR1XeHq9dkz3pGJywvXH3ljPLgJoOWZ4ToTsIO9o8Gv1smZCt R/XA== X-Gm-Message-State: AOAM533E0H0Knf2jq7ulQLzpAF6kymwA7d5NZ9u4INXIX4ZkQNqHpBsY f/NdoSc2xrNQOFnUNEqLh7tyH3rCf/1k88UzZpM= X-Google-Smtp-Source: ABdhPJzE1Zrs6LJvLlFprQ6XFr+mNSnKoJwnpwJb8zhZuLaluCoXeab7EX8mL6ac/+xrthuoApwBXH34ND6DScF1+d4= X-Received: by 2002:a17:906:7844:: with SMTP id p4mr14796325ejm.26.1603709277764; Mon, 26 Oct 2020 03:47:57 -0700 (PDT) MIME-Version: 1.0 References: <20201016121547.GA19073@nodbug.lucina.net> <20201026103746.GB11343@nodbug.lucina.net> <20201026104335.GC11343@nodbug.lucina.net> In-Reply-To: <20201026104335.GC11343@nodbug.lucina.net> From: Hans Ole Rafaelsen Date: Mon, 26 Oct 2020 11:47:46 +0100 Message-ID: Subject: Re: MirageOS on OpenStack problem To: Martin Lucina , mirageos-devel@lists.xenproject.org, Ricardo Koller Content-Type: multipart/alternative; boundary="000000000000d3026e05b290a971" --000000000000d3026e05b290a971 Content-Type: text/plain; charset="UTF-8" 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 > > > > --000000000000d3026e05b290a971 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 Projec= t developers

--
Hans Ole
<= /div>
O= n Mon, Oct 26, 2020 at 11:44 AM Martin Lucina <martin@lucina.net> wrote:
(Re-sending with a current email for Ricardo)<= br>
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
>

--000000000000d3026e05b290a971-- From mirageos-devel-bounces@lists.xenproject.org Mon Oct 26 21:40:30 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 26 Oct 2020 21:40:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.12543.32718 (Exim 4.92) (envelope-from ) id 1kXADy-0002S8-U7; Mon, 26 Oct 2020 21:40:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 12543.32718; Mon, 26 Oct 2020 21:40:18 +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 1kXADy-0002S1-RA; Mon, 26 Oct 2020 21:40:18 +0000 Received: by outflank-mailman (input) for mailman id 12543; Mon, 26 Oct 2020 18:33: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 1kX7JA-0002lj-47 for mirageos-devel@lists.xenproject.org; Mon, 26 Oct 2020 18:33:28 +0000 Received: from mail-ej1-x62e.google.com (unknown [2a00:1450:4864:20::62e]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3a7f8604-9330-4a0a-aabf-cbfca755c9fe; Mon, 26 Oct 2020 18:33:26 +0000 (UTC) Received: by mail-ej1-x62e.google.com with SMTP id k3so15095099ejj.10 for ; Mon, 26 Oct 2020 11:33:26 -0700 (PDT) Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kX7JA-0002lj-47 for mirageos-devel@lists.xenproject.org; Mon, 26 Oct 2020 18:33:28 +0000 X-Inumbo-ID: 3a7f8604-9330-4a0a-aabf-cbfca755c9fe Received: from mail-ej1-x62e.google.com (unknown [2a00:1450:4864:20::62e]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3a7f8604-9330-4a0a-aabf-cbfca755c9fe; Mon, 26 Oct 2020 18:33:26 +0000 (UTC) Received: by mail-ej1-x62e.google.com with SMTP id k3so15095099ejj.10 for ; Mon, 26 Oct 2020 11:33:26 -0700 (PDT) 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=wOncbAMrCwGzquDUcArrWHxEcWRF9BJsM8a2qv7zhX8=; b=gKdaAfXwSyWOl6Gtfgpyw77rLZmJs6xMKeDiWGrrkOWOnQnBSm+ww4z9ZXtTq5hSeP RLTcdrn1Y5nXf1nBf1zuwa8ezN7v29YtdiyyP+0Zc0RMC2YfEkIwFjzRTORbDfCOxtxX R3iLzWTC+fPsr5cxjFt1FIZP+QJP8pI8yg/dCYcxzkQPoPVUiJ19u0SeBL2UXfr8blXG XAji3RLLLQco+ILlrDnNVS4hSa0S9M/mdTYo20BsKOje35E6rjtspckQym9EidO/hpzx Jz1sHcF/P9pMpjpMI+RUqu3izbUhxvJsZQB06zt9tQ0bxjLNEz6KkflWxbSPBcEasZEs 16+A== 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=wOncbAMrCwGzquDUcArrWHxEcWRF9BJsM8a2qv7zhX8=; b=SysdhB7byYot678DU+1+dIvKBKbRmiupg+Fd73WyH2PwKXpOM+/Hsnj+LyF+1EM9gA ujiNJFJbyUcjTiWZ2nIkPkpeRaagnOuWYEhaAs+jv4kn4BBUoCeO5fQ5awqxDg1dPiua HDiGEDeenGhx3YL1WK+d3XlEJrWAWW4U+N12t2cQI9lRK7JS1G1fhthc+xsRpZrtvALG 0lNUHb5gf8p9AKk/05PJaNgJiWFv2+5taDHeQRn1h/NCEvXVisxFlR/NxF9B4JPCXETY yKMIUgqRAch5TbXMhP55yBUihENgWZJpxCvRKlpU058HgO7kLw65O7tUqtvT+fDz5oKa 3xbg== X-Gm-Message-State: AOAM533B54bV4kuEdBUaWTpHC66SI/rTNirSh6arnS/L0YXyhyfmavq1 WHh6/M4AzhJd5ZpBOoKM7VsVs7vUxnlSOi2FgtQ= X-Google-Smtp-Source: ABdhPJyAo7MFVEHKOQNqb66xCiAj2GjDSogVM0bRrJqooz2XR7FLRCeX5CFUjTMThqmqojuw9S2Sb4rtSqhjFmsF+Fg= X-Received: by 2002:a17:906:eb18:: with SMTP id mb24mr16931765ejb.172.1603737205689; Mon, 26 Oct 2020 11:33:25 -0700 (PDT) MIME-Version: 1.0 References: <20201016121547.GA19073@nodbug.lucina.net> <20201026103746.GB11343@nodbug.lucina.net> <20201026104335.GC11343@nodbug.lucina.net> In-Reply-To: From: Ricardo Koller Date: Mon, 26 Oct 2020 11:33:14 -0700 Message-ID: Subject: Re: MirageOS on OpenStack problem To: Hans Ole Rafaelsen Cc: Martin Lucina , mirageos-devel@lists.xenproject.org, Ricardo Koller Content-Type: multipart/alternative; boundary="000000000000755ddd05b2972a9d" --000000000000755ddd05b2972a9d Content-Type: text/plain; charset="UTF-8" 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 >> > >> >> --000000000000755ddd05b2972a9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

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

Ricardo

On Mon, Oct 26, 2020 at 3:48 AM Hans Ole Rafaelsen <<= a href=3D"mailto:hrafaelsen@gmail.com">hrafaelsen@gmail.com> wrote:<= br>
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, 2= 020 at 11:44 AM Martin Lucina <martin@lucina.net> wrote:
(Re-sending with a current email for Ricar= do)

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
>

--000000000000755ddd05b2972a9d-- From mirageos-devel-bounces@lists.xenproject.org Tue Oct 27 14:13:14 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 27 Oct 2020 14:13:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.12903.33391 (Exim 4.92) (envelope-from ) id 1kXPih-0005SD-FD; Tue, 27 Oct 2020 14:13:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 12903.33391; Tue, 27 Oct 2020 14:13:03 +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 1kXPih-0005S6-Ba; Tue, 27 Oct 2020 14:13:03 +0000 Received: by outflank-mailman (input) for mailman id 12903; Tue, 27 Oct 2020 14:13:01 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kXPif-0005Ng-M5 for mirageos-devel@lists.xenproject.org; Tue, 27 Oct 2020 14:13:01 +0000 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4d17d290-c339-455e-ab5a-8dac409db236; Tue, 27 Oct 2020 14:12:55 +0000 (UTC) Received: from nodbug.lucina.net (93-137-71-201.adsl.net.t-com.hr [93.137.71.201]) by smtp.lucina.net (Postfix) with ESMTPSA id 4ECDC122804; Tue, 27 Oct 2020 15:12:54 +0100 (CET) Received: by nodbug.lucina.net (Postfix, from userid 1000) id 5939A2683D52; Tue, 27 Oct 2020 15:12:53 +0100 (CET) Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kXPif-0005Ng-M5 for mirageos-devel@lists.xenproject.org; Tue, 27 Oct 2020 14:13:01 +0000 X-Inumbo-ID: 4d17d290-c339-455e-ab5a-8dac409db236 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4d17d290-c339-455e-ab5a-8dac409db236; Tue, 27 Oct 2020 14:12:55 +0000 (UTC) Received: from nodbug.lucina.net (93-137-71-201.adsl.net.t-com.hr [93.137.71.201]) by smtp.lucina.net (Postfix) with ESMTPSA id 4ECDC122804; Tue, 27 Oct 2020 15:12:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201811; t=1603807974; bh=h2OzsMInKjif+yY3DceG3feD9iaBujgGV9ZwqWPl4jw=; h=Date:From:To:Cc:Subject:From; b=TvSzT6I5LPOSShABikOcf1ng7ddfFojtXjZOuHBIObybR5blM90Blu3SVDy/SlQIj O8otzo1Xh+cL6zpO/31kx5ZAOAce/0gac1H4/AgBC06ZARSezcKMm03YaU72jBQ9DJ q15gt4ygSiuCK95TZriJLNPV6/6kZTQssh3/rk1IymeAK2wZjLPTBkxMs+cCAPRUwK cyQlI/FkW0cfgqWTafIw4q4/oJnO9HUAKeHW/F+fUFjGBHwRTCYfCPIlaFSwO/uwrd 4D3x7q1RcyythveykijyiDYhA4zWOA/iE2O/Pig7JJh2POz+fh4wyAEaGMQs2Bun3+ MbskA8aOJ4QvA== Received: by nodbug.lucina.net (Postfix, from userid 1000) id 5939A2683D52; Tue, 27 Oct 2020 15:12:53 +0100 (CET) Date: Tue, 27 Oct 2020 15:12:53 +0100 From: Martin Lucina To: mirageos-devel@lists.xenproject.org Cc: xen-devel@lists.xenproject.org Subject: [ANN] MirageOS 3.9.0 released Message-ID: <20201027141253.GA14637@nodbug.lucina.net> Mail-Followup-To: Martin Lucina , mirageos-devel@lists.xenproject.org, xen-devel@lists.xenproject.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.10.1 (2018-07-13) Dear all, We are pleased to announce the release of MirageOS 3.9.0. Our last release announcement was for [MirageOS 3.6.0](https://mirage.io/blog/announcing-mirage-36-release), so we will also cover changes since 3.7.x and 3.8.x in this announcement. New features: - The Xen backend has been [re-written from scratch](https://github.com/mirage/mirage/issues/1159) to be based on Solo5, and now supports PVHv2 on Xen 4.10 or higher, and QubesOS 4.0. - As part of this re-write, the existing Mini-OS based implementation has been retired, and all non-UNIX backends now use a unified OCaml runtime based on `ocaml-freestanding`. - OCaml runtime settings settable via the `OCAMLRUNPARAM` environment variable are now exposed as unikernel boot parameters. For details, refer to [#1180](https://github.com/mirage/mirage/pull/1180). Security posture improvements: - With the move to a unified Solo5 and ocaml-freestanding base MirageOS unikernels on Xen gain several notable improvements to their overall security posture such as SSP for all C code, W^X, and malloc heap canaries. For details, refer to the mirage-xen 6.0.0 release [announcement](https://github.com/mirage/mirage-xen/releases/tag/v6.0.0). API breaking changes: - Several Xen-specific APIs have been removed or replaced, unikernels using these may need to be updated. For details, refer to the mirage-xen 6.0.0 release [announcement](https://github.com/mirage/mirage-xen/releases/tag/v6.0.0). Other notable changes: - `Mirage_runtime` provides event loop enter and exit hook registration ([#1010](https://github.com/mirage/mirage/pull/1010)). - All MirageOS backends now behave similarly on a successful exit of the unikernel: they call `exit` with the return value 0, thus `at_exit` handlers are now executed ([#1011](https://github.com/mirage/mirage/pull/1011)). - The unix backend used a toplevel exception handler, which has been removed. All backends now behave equally with respect to exceptions. - Please note that the `Mirage_net.listen` function still installs an exception handler, which will be removed in a future release. The out of memory exception is no longer caught by `Mirage_net.listen` ([#1036](https://github.com/mirage/mirage/issues/1036)). - To reduce the number of OPAM packages, the `mirage-*-lwt` packages are now deprecated. `Mirage_net` (and others) now use `Lwt.t` directly, and their `buffer` type is `Cstruct.t` ([#1004](https://github.com/mirage/mirage/issues/1004)). - OPAM files generated by `mirage configure` now include opam build and installation instructions, and also an URL to the Git `origin` ([#1022](https://github.com/mirage/mirage/pull/1022)). Known issues: - `mirage configure` fails if the unikernel is under version control and no `origin` remote is present ([#1188](https://github.com/mirage/mirage/issues/1188)). - The Xen backend has issues with event delivery if built with an Alpine Linux GCC toolchain. As a work-around, please use a Fedora or Debian based toolchain. Acknowledgements: - Thanks to Roger Pau Monné, Andrew Cooper and other core Xen developers for help with understanding the specifics of how Xen PVHv2 works, and how to write an implementation from scratch. - Thanks to Marek Marczykowski-Górecki for help with the QubesOS specifics, and for forward-porting some missing parts of PVHv2 to QubesOS version of Xen. - Thanks to @palainp on Github for help with testing on QubesOS. From mirageos-devel-bounces@lists.xenproject.org Fri Oct 30 19:55:17 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 30 Oct 2020 19:55:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.16222.39621 (Exim 4.92) (envelope-from ) id 1kYaUJ-000839-71; Fri, 30 Oct 2020 19:55:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 16222.39621; Fri, 30 Oct 2020 19:55:03 +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 1kYaUJ-000832-2t; Fri, 30 Oct 2020 19:55:03 +0000 Received: by outflank-mailman (input) for mailman id 16222; Fri, 30 Oct 2020 19:55:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kYaUI-00082x-0p for mirageos-devel@lists.xenproject.org; Fri, 30 Oct 2020 19:55:02 +0000 Received: from mail-ed1-x533.google.com (unknown [2a00:1450:4864:20::533]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 63828398-ff76-48e9-9936-7dd4097d10d1; Fri, 30 Oct 2020 19:54:59 +0000 (UTC) Received: by mail-ed1-x533.google.com with SMTP id l16so7899895eds.3 for ; Fri, 30 Oct 2020 12:54:59 -0700 (PDT) Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kYaUI-00082x-0p for mirageos-devel@lists.xenproject.org; Fri, 30 Oct 2020 19:55:02 +0000 X-Inumbo-ID: 63828398-ff76-48e9-9936-7dd4097d10d1 Received: from mail-ed1-x533.google.com (unknown [2a00:1450:4864:20::533]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 63828398-ff76-48e9-9936-7dd4097d10d1; Fri, 30 Oct 2020 19:54:59 +0000 (UTC) Received: by mail-ed1-x533.google.com with SMTP id l16so7899895eds.3 for ; Fri, 30 Oct 2020 12:54:59 -0700 (PDT) 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=M3hDMgYsg+PBmCtEEFg3W2mzS7jCHZdTiBaFOnEtVvE=; b=P3EI0AD0QzUtkP3c5TbM33YsJlk/2jL49GOIQIAC7GdHj5L8CZ7v02m2V7SOevSAbQ eQVKGdlqlVuFWDvSvfSnl12t0GcDiP5D/W2HrkwQqn+I57rh/0PoufRd8JIh4lIUaP3M Igpo+uJIW7sGhYJEGDQ7wqLf+wQMZlwPa/po0llLZS2suW+BPwQxiBOhVl6F+Ulcsh4d 2+OxAGEAomyqow5ev+sd2jugMhV//HBfbc6rVh1eibbMKVzNWodR2xFqAVFc160qkY9m oFUjUUP5YLh3QwuyLcL0HXebau8acMrxCAZfq5O6jDsvFMu5OyjHnaNqqU19HacYJQb9 qfkw== 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=M3hDMgYsg+PBmCtEEFg3W2mzS7jCHZdTiBaFOnEtVvE=; b=GZIzvXdnYo4Ywn305nfCjjeLGDF7eXYUNLLwcYlUQaLLSrTxnsuDtHNG5ndW5wjKdk IejL0ldlH+7+Be+pr02bcyCAn3QN84IboB7tQg0r2WaXX8ubZZLNP6bL5tDcpPeDio9A Lqn20rxm3qsAmJ8EkOA+v9PTW8FpTe99B6z74rDfAzce76kC4wqHJczZIBae2Ywp8Yaw tJpPbQdg++9ZC5crk9uScXNzxrOwI6t8DacKmJ6XQjH984Bg+ekkijD5ap4bBiOwcmmQ uuE9dKOscH1qvpxCnW9qc1dk6BLUfbgm3CyxZ/afYBud/Evma2ongMJrGVzfryvFec5u naiA== X-Gm-Message-State: AOAM530JlYEUwvq+CJ8lJ969Dg2w47v7KYRDtbY6cxj2mlK8JiBPfxtY tW/7a1gUcs+uiMDx1ulu9NKjPh5NqjjUsdkRtFy1BTmRSpeDVQ== X-Google-Smtp-Source: ABdhPJzlNHy005CbSc2VGKCQdUILaFcJqOn/QGpoh2JODubCNHWbogaHC87r3+QcXx7U0kbZGE0AVUmJbjCxJgs9oOE= X-Received: by 2002:aa7:cd42:: with SMTP id v2mr4081417edw.191.1604087698865; Fri, 30 Oct 2020 12:54:58 -0700 (PDT) MIME-Version: 1.0 References: <20201016121547.GA19073@nodbug.lucina.net> <20201026103746.GB11343@nodbug.lucina.net> <20201026104335.GC11343@nodbug.lucina.net> In-Reply-To: From: Ricardo Koller Date: Fri, 30 Oct 2020 12:54:47 -0700 Message-ID: Subject: Re: MirageOS on OpenStack problem To: Hans Ole Rafaelsen Cc: Martin Lucina , mirageos-devel@lists.xenproject.org, Ricardo Koller Content-Type: multipart/alternative; boundary="0000000000007ac34e05b2e8c551" --0000000000007ac34e05b2e8c551 Content-Type: text/plain; charset="UTF-8" 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 >>> > >>> >>> --0000000000007ac34e05b2e8c551 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Was able to reproduce it and now have a bett= er idea of what's going on (with a temporary fix included). The issue h= appens when using qemu with a boot disk image exposed as a virtio-blk devic= e. The problem is that solo5 tries to configure a virtio device that was al= ready initialized/configured at VM early boot time. Qemu gets "confuse= d" with the second configuration attempt, throws the "virtio: zer= o sized buffers are not allowed" error and gets stuck (somewhere that = I couldn't determine).

Just in case, these are all the tests I t= ried (using qemu v3 as v5 has an issue https://github.com/Solo5/solo5/issues/463). To make t= hings simpler I've been using the solo5 tests/test-net unikernel (c cod= e, not mirage). You can create disk-net.img in solo5 using:
tests (maste= r) [83]> ../scripts/virtio-mkimage/solo5-virtio-mkimage.sh -f raw disk-n= et.img test_net/test_net.virtio

These work:
+=C2=A0boot disk imag= e as an IDE device:
qemu-3 -drive file=3Ddisk-net.img,if=3Dide,format= =3Draw -cpu Westmere -m 128 -nodefaults -no-acpi -display none \
-seria= l stdio -device virtio- net,netdev=3Dn0 -netdev tap,id=3Dn0,ifname=3Dtap100= ,script=3Dno,downscript=3Dno -device isa-debug-exit

+boot disk = image as a virtio-scsi device (same as google cloud):
qemu-3 -device vir= tio-scsi-pci,id=3Dscsi \
-device scsi-hd,drive=3Dhd \
-drive if=3Dn= one,id=3Dhd,file=3Ddisk-net.img,format=3Draw \
-cpu Westmere -m 128 -no= defaults -no-acpi -display none -serial stdio \
-device virtio-net,netd= ev=3Dn0 -netdev tap,id=3Dn0,ifname=3Dtap100,script=3Dno,downscript=3Dno -de= vice isa-debug-exit

These do NOT work:
+=C2=A0boot disk image as = a virtio-blk device:
qemu-3 -drive file=3Ddisk-net.img,if=3Dvirtio,forma= t=3Draw -cpu Westmere -m 128 -nodefaults -no-acpi -display none \
-seri= al stdio -device virtio-net,netdev=3Dn0 -netdev tap,id=3Dn0,ifname=3Dtap100= ,script=3Dno,downscript=3Dno -device isa-debug-exit

The right fix wo= uld be to check in solo5 init code that the virtio device is already config= ured, and just skip it. For now, this temporary patch (disable virtio-blk c= ompletely) 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/virtio/pci.c
+++ b/bindings/virtio/pci.c=
@@ -54,7 +54,6 @@
=C2=A0
=C2=A0
=C2=A0static uint32_t net_devi= ces_found;
-static uint32_t blk_devices_found;
=C2=A0
=C2=A0#defin= e PCI_CONF_SUBSYS_NET 1
=C2=A0#define 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:%0= 2x: 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=A0case PCI_CONF_SUBSYS_BLK:
- =C2=A0 =C2= =A0 =C2=A0 =C2=A0log(INFO, "Solo5: 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);
- =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->dev);
- =C2=A0 =C2=A0 =C2=A0 = =C2=A0break;
=C2=A0 =C2=A0 =C2=A0default:
=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, 20= 20 at 11:33 AM Ricardo Koller <ric= arkol@gmail.com> 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 <hra= faelsen@gmail.com> wrote:
Hi,

<= /div>
$ qemu-system-x86_64 --version
QEMU emulator version 2.11.1(De= bian 1:2.11+dfsg-1ubuntu7.32)
Copyright (c) 2003-2017 Fabrice Bellard an= d the QEMU Project developers

--
Ha= ns Ole

On Mon, Oct 26, 2020 at 11:44 AM Martin Lucina <martin@lucina.net> w= rote:
(Re-sendin= g 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
>

--0000000000007ac34e05b2e8c551--