On Mon, Jan 29, 2018 at 12:07:50PM +0100, Artur Pedziwilk wrote: > > > > On 11 Jan 2018, at 15:40, Karel Gardas <gard...@gmail.com> wrote: > > > > - cloud/kvm solution. There are several cloud provides already > > selling/supporting Cavium ThunderX > > and for quite cheap money. Anyone has a luck with this solution? I guess > > OpenBSD would need to run on > > qemu-system-aarch64 first to support all those kvm/virtio devices needed > > and then grabed to cloud, but still > > any chance? > > > Yesterday, I have managed to run the current of arm64 on scaleway.com... > > ... by resizing the miniroot62.fs, partitioning it and installing it very > analogically to > Antoine's "create-ami.sh" - https://github.com/ajacoutot/aws-openbsd > > Later I just simply "dd if=myimage.fs of=/dev/vdb bs=1m" > from Linux instance with 2 disks attached and reboot the disk with new fresh > instance. > It is basically working but many "Segmentation fault (core dumped)". > I intend to keep that instance running and check it with incoming snapshots. > > OpenBSD 6.2-current (GENERIC) #160: Wed Jan 24 18:26:59 MST 2018 > dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC > real mem = 2090483712 (1993MB) > avail mem = 2002345984 (1909MB) > mainbus0 at root: unknown model > cpu0 at mainbus0: Cavium ThunderX T88 r1p1 > efi0 at mainbus0: UEFI 2.6 > efi0: EDK II rev 0x10000 > psci0 at mainbus0: PSCI 0.2 > simplebus0 at mainbus0: "platform" > virtio0 at mainbus0: Virtio Unknown (0) Device > virtio1 at mainbus0: Virtio Unknown (0) Device > virtio2 at mainbus0: Virtio Unknown (0) Device > virtio3 at mainbus0: Virtio Unknown (0) Device > virtio4 at mainbus0: Virtio Unknown (0) Device > virtio5 at mainbus0: Virtio Unknown (0) Device > virtio6 at mainbus0: Virtio Unknown (0) Device > virtio7 at mainbus0: Virtio Unknown (0) Device > virtio8 at mainbus0: Virtio Unknown (0) Device > virtio9 at mainbus0: Virtio Unknown (0) Device > virtio10 at mainbus0: Virtio Unknown (0) Device > virtio11 at mainbus0: Virtio Unknown (0) Device > virtio12 at mainbus0: Virtio Unknown (0) Device > virtio13 at mainbus0: Virtio Unknown (0) Device > virtio14 at mainbus0: Virtio Unknown (0) Device > virtio15 at mainbus0: Virtio Unknown (0) Device > virtio16 at mainbus0: Virtio Unknown (0) Device > virtio17 at mainbus0: Virtio Unknown (0) Device > virtio18 at mainbus0: Virtio Unknown (0) Device > virtio19 at mainbus0: Virtio Unknown (0) Device > virtio20 at mainbus0: Virtio Unknown (0) Device > virtio21 at mainbus0: Virtio Unknown (0) Device > virtio22 at mainbus0: Virtio Unknown (0) Device > virtio23 at mainbus0: Virtio Unknown (0) Device > virtio24 at mainbus0: Virtio Unknown (0) Device > virtio25 at mainbus0: Virtio Unknown (0) Device > virtio26 at mainbus0: Virtio Unknown (0) Device > virtio27 at mainbus0: Virtio Unknown (0) Device > virtio28 at mainbus0: Virtio Unknown (0) Device > virtio29 at mainbus0: Virtio Unknown (0) Device > virtio30 at mainbus0: Virtio Unknown (0) Device > virtio31 at mainbus0: Virtio Unknown (0) Device > pciecam0 at mainbus0 > pci0 at pciecam0 > "Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured > virtio32 at pci0 dev 1 function 0 "Qumranet Virtio Network" rev 0x00 > vio0 at virtio32: address de:2b:88:06:60:4f > virtio32: irq > virtio33 at pci0 dev 2 function 0 "Qumranet Virtio Storage" rev 0x00 > vioblk0 at virtio33 > scsibus0 at vioblk0: 2 targets > sd0 at scsibus0 targ 0 lun 0: <VirtIO, Block Device, > SCSI3 0/direct fixed > sd0: 47683MB, 512 bytes/sector, 97656250 sectors > virtio33: irq > pluart0 at mainbus0: console > agintc0 at mainbus0 nirq 288, nredist 4 > agtimer0 at mainbus0: tick rate 100000 KHz > vscsi0 at root > scsibus1 at vscsi0: 256 targets > softraid0 at root > scsibus2 at softraid0: 256 targets > bootfile: sd0a:/bsd > boot device: sd0 > root on sd0a (11af0f37e1af6b1a.a) swap on sd0b dump on sd0b >
First of all, I'm positively surprised. When I worked on Scaleway's bare metal ARMv7 instances, the system was supposed to boot with an initramdisk which then mounts a network block device and pivot roots into this mountpoint. This would right now not be doable with Open- BSD. In this case these are virtual machines running on their Caviums, which is "nicer" for us because it abstracts the NBD away and we only see virtual disks. On the other hand, we run on a virtual machine and not on physical hardware. There might be some quirks necessary for the ThunderX CPUs. At least afaik there are some quirks in the Linux kernel. I think those random segfaults might even be visible with qemu running on an x86 machine. I'm not surprised.
