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 <hrafael...@gmail.com> 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 <mar...@lucina.net> 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 >> > >> >>
