On Mon, Jan 29, 2018 at 02:14:53PM +0100, Patrick Wildt wrote: > On Mon, Jan 29, 2018 at 12:07:50PM +0100, Artur Pedziwilk wrote: > > > > > > > On 11 Jan 2018, at 15:40, Karel Gardas <[email protected]> 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 > > [email protected]:/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. >
jsg@ just reminded me that my memory is fading. I actually ran on that Scaleway platform already, hence why we added the proper prints for the Cavium CPUs: http://ix.io/sA2 I wasn't sure anymore since I also tried to run on the packet.net ARMs, but the machine hung on bootup, rather early.
