Question about strange panic with NetBSD-domu versus FreeBSD dom0.

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	hello.  I have a NetBSD domu, NetbSD-99.77 from sources of January 2021, running under
FreeBSD-13.1, Xen-4.16.0on an AMD64 server that's been running without an issue for a year and
4 months.  Last week, it started panicing with the following message:

[ 73069.0789801] panic: kernel diagnostic assertion "x86_read_psl() == 0" failed: file "/usr/local/netbsd/src-current/sys/arch/x86/x86/pmap.c", line 3509 

	Now, this particular domu panics multiple times a day with no software or hardware change,
always in the same spot in x86/x86/pmap.c.  Interestingly enough, I have other servers running
this exact same combination of software, with a number of domus, all running this same build of
NetBSD, that don't exhibit this behavior at all.

	My question is, is this a hardware issue, an issue with the xen hypervisor, with
FreeBSD-13.1 as dom0, or with the domu NetBSD?  As an additional data point, I'm running an old
NetBSD-5.2 domu on this system as well, and it doesn't exhibit this behavior, but I attribute
that to the fact that it doesn't perform the x86_read_psl() call when configured as a domu.  
What does the x86_read_psl() call do?  It looks like a register read, but I can't find the
function in the source tree to read it.

	When the domu in question fails, it's running a build release.  all the tracebacks look
the same, but what I don't understand, is what has changed between when it worked and now.  I'm
building the same source tree now as when it was working, and the system is doing nothing else
at the time these panics occur. The traceback is shown below.  

	I'd be interested to know if anyone else has seen this behavior under any version of
NetBSD and xen, or if folks know if it's a hardware or Xen hypervisor issue.

-thanks
-Brian


[ 73069.0789801] panic: kernel diagnostic assertion "x86_read_psl() == 0" failed: file "/usr/local/netbsd/src-current/sys/arch/x86/x86/pmap.c", line 3509 
[ 73069.0789801] cpu1: Begin traceback...
[ 73069.0789801] vpanic() at netbsd:vpanic+0x14a
[ 73069.0789801] kern_assert() at netbsd:kern_assert+0x48
[ 73069.0789801] pmap_load() at netbsd:pmap_load+0x12d
[ 73069.0789801] do_pmap_load() at netbsd:do_pmap_load+0x1d
[ 73069.0789801] copyout() at netbsd:copyout+0x48
[ 73069.0789801] syscall() at netbsd:syscall+0x9c
[ 73069.0789801] --- syscall (number 449) ---
[ 73069.0789801] netbsd:syscall+0x9c:
[ 73069.0789801] cpu1: End traceback...
[ 73069.0789801] fatal breakpoint trap in supervisor mode
[ 73069.0789801] trap type 1 code 0 rip 0xffffffff8022d93d cs 0x10000e030 rflags 0x2 cr2 0x780c8db842e0 ilevel 0 rsp 0xffffad02297b2cc0
[ 73069.0789801] curlwp 0xffffad00112c6180 pid 19540.19540 lowest kstack 0xffffad02297ae2c0
Stopped in pid 19540.19540 (nbmkdep) at netbsd:breakpoint+0x5:  leave