Stafford and I have been using this to shake out OpenRISC bugs, and it's
been a great help, so it's time OpenRISC support for the WireGuard test
suite is made into a proper commit. The QEMU changes necessary for this
to work should also be around the corner now, and they seem some what
stationary in their interface too.
Cc: Stafford Horne <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>
---
.../testing/selftests/wireguard/qemu/Makefile | 13 ++++++++++-
.../selftests/wireguard/qemu/arch/or1k.config | 22 +++++++++++++++++++
2 files changed, 34 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/wireguard/qemu/arch/or1k.config
diff --git a/tools/testing/selftests/wireguard/qemu/Makefile b/tools/testing/selftests/wireguard/qemu/Makefile
index 7d1b80988d8a..57b00578b86f 100644
--- a/tools/testing/selftests/wireguard/qemu/Makefile
+++ b/tools/testing/selftests/wireguard/qemu/Makefile
@@ -247,8 +247,19 @@ QEMU_MACHINE := -cpu host,accel=kvm -machine s390-ccw-virtio -append $(KERNEL_CM
else
QEMU_MACHINE := -cpu max -machine s390-ccw-virtio -append $(KERNEL_CMDLINE)
endif
+else ifeq ($(ARCH),or1k)
+CHOST := or1k-linux-musl
+QEMU_ARCH := or1k
+KERNEL_ARCH := openrisc
+KERNEL_BZIMAGE := $(KERNEL_BUILD_PATH)/vmlinux
+QEMU_VPORT_RESULT := virtio-serial-device
+ifeq ($(HOST_ARCH),$(ARCH))
+QEMU_MACHINE := -cpu host,accel=kvm -machine virt
+else
+QEMU_MACHINE := -cpu or1200 -machine virt
+endif
else
-$(error I only build: x86_64, i686, arm, armeb, aarch64, aarch64_be, mips, mipsel, mips64, mips64el, powerpc64, powerpc64le, powerpc, m68k, riscv64, riscv32, s390x)
+$(error I only build: x86_64, i686, arm, armeb, aarch64, aarch64_be, mips, mipsel, mips64, mips64el, powerpc64, powerpc64le, powerpc, m68k, riscv64, riscv32, s390x, or1k)
endif
TOOLCHAIN_FILENAME := $(CHOST)-cross.tgz
diff --git a/tools/testing/selftests/wireguard/qemu/arch/or1k.config b/tools/testing/selftests/wireguard/qemu/arch/or1k.config
new file mode 100644
index 000000000000..164dce530ccb
--- /dev/null
+++ b/tools/testing/selftests/wireguard/qemu/arch/or1k.config
@@ -0,0 +1,22 @@
+CONFIG_OPENRISC_HAVE_INST_FF1=y
+CONFIG_OPENRISC_HAVE_INST_FL1=y
+CONFIG_OPENRISC_HAVE_INST_MUL=y
+CONFIG_OPENRISC_HAVE_INST_DIV=y
+CONFIG_OPENRISC_HAVE_INST_CMOV=y
+CONFIG_OPENRISC_HAVE_INST_ROR=y
+CONFIG_OPENRISC_HAVE_INST_RORI=y
+CONFIG_OPENRISC_HAVE_INST_SEXT=y
+CONFIG_OPENRISC_NO_SPR_SR_DSX=y
+CONFIG_JUMP_UPON_UNHANDLED_EXCEPTION=y
+CONFIG_COMPAT_32BIT_TIME=y
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_VIRTIO_MENU=y
+CONFIG_VIRTIO_MMIO=y
+CONFIG_VIRTIO_CONSOLE=y
+CONFIG_POWER_RESET=y
+CONFIG_POWER_RESET_SYSCON=y
+CONFIG_POWER_RESET_SYSCON_POWEROFF=y
+CONFIG_SYSCON_REBOOT_MODE=y
+CONFIG_CMDLINE="console=ttyS0 wg.success=vport0p1 panic_on_warn=1"
--
2.35.1
On Tue, Jun 28, 2022 at 02:02:10AM +0200, Jason A. Donenfeld wrote:
> Stafford and I have been using this to shake out OpenRISC bugs, and it's
> been a great help, so it's time OpenRISC support for the WireGuard test
> suite is made into a proper commit. The QEMU changes necessary for this
> to work should also be around the corner now, and they seem some what
> stationary in their interface too.
>
> Cc: Stafford Horne <[email protected]>
> Signed-off-by: Jason A. Donenfeld <[email protected]>
Hello,
I am not sure what happened to my reply on this yesterday, but I did have this
queued for 5.19 fixes. However, as we just discussed there are still some soft
lockup issues that cause 'rcu: INFO: rcu_preempt detected stalls' noise.
I will hold off sending this upstream for now.
Example isssues:
- https://א.cc/x3Vt402T
- https://xn--4db.cc/bKiNzmFE
-Stafford
On Tue, Jun 28, 2022 at 04:36:34PM -0400, Joe R wrote:
> Thank you for the patch, it seems like you put in a lot of time into it.
>
> However, I do have one question: on the website
> (https://www.wireguard.com/build-status/) it says that the test is
> still failing. Is that due to the QEMU changes that have yet to be
> upstream, or is it outdated and has already been fixed?
>
> Thanks again for all the hard work you do!
Hi,
Jason mentioned this to me too. There are still some stability issues under
load that cause the platform to be unstable.
We will need to sort these out before turning this on. So this is on hold for
now.
-Stafford
Thank you for the patch, it seems like you put in a lot of time into it.
However, I do have one question: on the website
(https://www.wireguard.com/build-status/) it says that the test is
still failing. Is that due to the QEMU changes that have yet to be
upstream, or is it outdated and has already been fixed?
Thanks again for all the hard work you do!