On Sun, Feb 04, 2024 at 01:58:17PM +0100, Peter J. Philipp wrote: > Hi, > > I just reinstalled a host and noticed the following two conditions: > > 1. BOOTRISCV64.EFI does not get installed on the outer (non-sr0) partition i. > in the installer. This means I cannot boot without booting from a > different image and fixing it. It was a one time thing but it is a > bit of a waste of time?
Quite a surprise, I'm quite sure riscv64 was tested on real hardware when disk encryption support landed in the installer. MD installer code also reads the same between arm64 and riscv64, both EFI platforms share identical installboot(8) usage and code. I don't have a riscv64 (or arm64) machine at hand, but they really ought to work. > 2. After entering the crypted passphrase one can enter load commands at boot: > pressing enter causes a long delay for some reason on a RISCV64 qemu > on an amd64 vps running windows. It takes a lot longer than > non-encrypted to load the bootblocks (which makes sense though its long) > in "booting sr0a:/bsd:this\" and I'm guessing there is something > in the offloading that is really slow. Once the kernel is booted > there is 5% more CPU usage on the windows host probably due to the > softraid crypto. As I wrote this entire email this is still in 'this\' > we're looking at 9 minutes or so so far. Also during those 9 min, the > CPU on the host OS (windows) is at 100% which is weird because afaik > the BOOTRISCV64.EFI is not multithreaded (smp?). > > After 14 minutes it finally continued loading the second block > (symbols?) this seems excessive. I have attached a screenshot on > what I really mean. Have you tried real hardware? I don't quite trust QEMU and/or Windows to properly emulate riscv64. Does regress/usr.sbin/installboot/ pass in your VM? Here it does: http://bluhm.genua.de/regress/results/2024-02-03T16%3A17%3A05Z/logs/usr.sbin/installboot/make.log > dmesg follows: > > OpenBSD 7.4-current (GENERIC.MP) #473: Tue Jan 30 06:55:55 MST 2024 > [email protected]:/usr/src/sys/arch/riscv64/compile/GENERIC.MP > real mem = 2147483648 (2048MB) > avail mem = 2023960576 (1930MB) > SBI: OpenSBI v1.2, SBI Specification Version 1.0 > random: good seed from bootblocks > mainbus0 at root: riscv-virtio,qemu > cpu0 at mainbus0: vendor 0 arch 0 imp 0 > rv64imafdch_zicbom_zicboz_zicntrv\M-7[\M^P\M-+\M-WoI\M-pP\M-# > intc0 at cpu0 > cpu1 at mainbus0: vendor 0 arch 0 imp 0 > rv64imafdch_zicbom_zicboz_zicntrv\M-7[\M^P\M-+\M-WoI > syscon0 at mainbus0: "poweroff" > syscon1 at mainbus0: "reboot" > simplebus0 at mainbus0: "platform-bus" > "pmu" at mainbus0 not configured > "fw-cfg" at mainbus0 not configured > "flash" at mainbus0 not configured > simplebus1 at mainbus0: "soc" > syscon2 at simplebus1: "test" > plic0 at simplebus1 > gfrtc0 at simplebus1 > com0 at simplebus1: ns16550, no working fifo > com0: console > pciecam0 at simplebus1 > pci0 at pciecam0 > "Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured > virtio0 at simplebus1: Virtio Network Device > vio0 at virtio0: address 52:54:00:12:34:56 > virtio1 at simplebus1: Virtio Block Device > vioblk0 at virtio1 > scsibus0 at vioblk0: 1 targets > sd0 at scsibus0 targ 0 lun 0: <VirtIO, Block Device, > > sd0: 8192MB, 512 bytes/sector, 16777216 sectors > virtio2 at simplebus1: Virtio Block Device > vioblk1 at virtio2 > scsibus1 at vioblk1: 1 targets > sd1 at scsibus1 targ 0 lun 0: <VirtIO, Block Device, > > sd1: 8192MB, 512 bytes/sector, 16777216 sectors > virtio3 at simplebus1: Virtio Unknown (0) Device > virtio4 at simplebus1: Virtio Unknown (0) Device > virtio5 at simplebus1: Virtio Unknown (0) Device > virtio6 at simplebus1: Virtio Unknown (0) Device > virtio7 at simplebus1: Virtio Unknown (0) Device > "clint" at simplebus1 not configured > vscsi0 at root > scsibus2 at vscsi0: 256 targets > softraid0 at root > scsibus3 at softraid0: 256 targets > sd2 at scsibus3 targ 1 lun 0: <OPENBSD, SR CRYPTO, 006> > sd2: 8159MB, 512 bytes/sector, 16711152 sectors > root on sd2a (78574edc31b04e33.a) swap on sd2b dump on sd2b > > Best Regards, > -peter
