Re: MirageOS on OpenStack problem

[Martin Lucina <martin@xxxxxxxxxx>]

(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
>