On 8/13/25 7:33 AM, Dave Voutila wrote:
Adrian Ali <adrian...@fortix.com.ar> writes:
Hello, my installation:
OpenBSD Release 7.7 amd64
server ~ aali $ uname -a
OpenBSD server.fortix.com.ar 7.7 GENERIC.MP#2 amd64
server ~ aali $
server ~ aali $ syspatch -l
001_nfs
002_zic
003_zoneinfo
004_pfsyncook
005_acme
006_xserver
007_xserver
008_pledge
server ~ aali $
When booting a Linux guest with the 6.12 kernel on VMM:
vmctl start -c -n uplink_veb0 -m 512M -i 1 -r
install-amd64-minimal-20250810T165238Z.iso -d gentoo.qcow2 gentoo
it produces the error:
[ 2.798040] ------------[ cut here ]------------
[ 2.799107] WARNING: CPU: 0 PID: 1 at
arch/x86/kernel/fpu/xstate.c:1009 get_xsave_addr_user+0x48/0x80
[ 2.801157] Modules linked in:
[ 2.801830] CPU: 0 UID: 0 PID: 1 Comm: init Not tainted 6.12.38 #1
[ 2.803160] Hardware name: OpenBSD VMM, BIOS 1.16.3p0-OpenBSD-vmm
01/01/2011
[ 2.804676] RIP: 0010:get_xsave_addr_user+0x48/0x80
[ 2.805731] Code: 00 00 48 d3 e2 48 23 15 ae 4f e9 01 74 1c 48 63
c9 48 83 f9 13 73 20 8b 14 8d 00 19 ef bc 48 83 c4 10 48 01 d0 c3 cc
cc cc cc <0f> 0b 31 c0 48 83 c4 10 e9 5b 14 2c 01 48 89 ce 48 c7 c7 e0
d6 83
[ 2.809755] RSP: 0018:ffffd3e5c000bd08 EFLAGS: 00010246
[ 2.810901] RAX: 00007ffe83371640 RBX: 0000000000000000 RCX:
0000000000000009
[ 2.812444] RDX: 0000000000000000 RSI: 0000000000000009 RDI:
00007ffe83371640
[ 2.814014] RBP: ffff8c49812ff9c0 R08: ffffd3e5c000be28 R09:
0000000000000000
[ 2.815850] R10: 0000000000000000 R11: 0000000000000010 R12:
00007ffe83371640
[ 2.817366] R13: ffff8c49812ff980 R14: 00007ffe83371640 R15:
ffff8c49812fd380
[ 2.818880] FS: 00007f8f95584d40(0000) GS:ffff8c499f400000(0000)
knlGS:0000000000000000
[ 2.820747] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050013
[ 2.821987] CR2: 000055ba5c099774 CR3: 0000000001094000 CR4:
0000000000f50eb0
[ 2.823518] PKRU: 00000000
[ 2.824119] Call Trace:
[ 2.824670] <TASK>
[ 2.825150] copy_fpstate_to_sigframe+0x203/0x3a0
[ 2.826197] get_sigframe+0xf6/0x280
[ 2.826993] x64_setup_rt_frame+0x6c/0x2f0
[ 2.827887] arch_do_signal_or_restart+0x1cd/0x260
[ 2.828929] syscall_exit_to_user_mode+0x172/0x200
[ 2.830001] do_syscall_64+0x8e/0x190
[ 2.830826] ? exc_page_fault+0x7e/0x180
[ 2.831726] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 2.832891] RIP: 0033:0x7f8f9565a638
[ 2.833680] Code: 48 85 f6 74 15 48 b9 00 00 00 80 01 00 00 00 48
8b 06 48 85 c8 75 43 48 89 f0 48 89 c6 41 ba 08 00 00 00 b8 0e 00 00
00 0f 05 <89> c2 f7 da 3d 00 f0 ff ff b8 00 00 00 00 0f 47 c2 48 8b 94
24 88
[ 2.837671] RSP: 002b:00007ffe83371a30 EFLAGS: 00000246 ORIG_RAX:
000000000000000e
[ 2.839429] RAX: 0000000000000000 RBX: 000000000000004b RCX:
00007f8f9565a638
[ 2.840950] RDX: 0000000000000000 RSI: 00007ffe83371b90 RDI:
0000000000000002
[ 2.842477] RBP: 0000000000000001 R08: 00007f8f957a3ac0 R09:
0000000000000001
[ 2.844004] R10: 0000000000000008 R11: 0000000000000246 R12:
00007ffe83371b10
[ 2.845461] R13: 00007ffe83371c10 R14: 000055ba5c066ecc R15:
000055ba79e33580
[ 2.846976] </TASK>
[ 2.847440] ---[ end trace 0000000000000000 ]---
It crashes the kernel and boot failed. I tested with a Linux guest
"kernel 6.12.31-gentoo" and with the Gentoo minimal installation image
"install-amd64-minimal-20250810T165238Z.iso" which comes with a kernel
version "Linux version 6.12.38".
On the host:
tail -f /var/log/daemon
Aug 12 23:04:21 server vmd[89690]: started gentoo (vm 1) successfully,
tty /dev/ttypu
Searching, I found a report that the Linux kernel 6.12 branch also has
problems with the VZ hypervisor of macOS. A workaround is to disable
the "CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS" option at Linux kernel
boot by adding the "nopku" argument to the kernel. The link with the
error details and how to solve it in VZ (it works the same in VMM):
Did you try this boot arg? If so, does it help?
Can you provide a dmesg output of your host OpenBSD system, too?
I'll look to reproduce today.
https://github.com/lima-vm/lima/issues/3334
My question is whether there is a report on this issue?
Nope. First I've seen this! Thanks for raising it. In the future it's
best to send to b...@openbsd.org as things can be lost in the noise on
misc@.
I sent the query to this mailing list because I wasn't sure if it was a
bug or an unimplemented feature that was incompatible with my setup.
Thanks.
