port-xen/53557: NetBSD 7.1.2 Xen dom0 panics on unclean shutdown

[gson%gson.org@localhost (Andreas Gustafsson)]

>Number:         53557
>Category:       port-xen
>Synopsis:       NetBSD 7.1.2 Xen dom0 panics on unclean shutdown
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    port-xen-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Aug 27 14:40:00 +0000 2018
>Originator:     Andreas Gustafsson
>Release:        NetBSD 7.1.2
>Organization:
>Environment:
System: NetBSD
Architecture: x86_64
Machine: amd64
>Description:

When I tried to "halt -p" a NetBSD 7.1.1/amd64 Xen dom0 that I had set
up for testing and that still had some test domUs running off vnd
devices, not caring about doing a clean shutdown because I was going
to wipe the system anyway, it paniced during shutdown and rebooted
instead of powering off like I had asked it to.

Console output from around the panic:

vnd2: detached
vnd1: detached
vnd0: detached
fatal integer divide fault in supervisor mode
trap type 8 code 0 rip ffffffff806f8fcd cs e030 rflags 10293 cr2 7f7ff25570c8 ilevel 0 rsp ffffa0001c01de58
curlwp 0xffffa00000ed8520 pid 0.77 lowest kstack 0xffffa0001c01b2c0
Skipping crash dump on recursive panic
panic: trap
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x13c
snprintf() at netbsd:snprintf
startlwp() at netbsd:startlwp
alltraps() at netbsd:alltraps+0x9f
cpu0: End traceback...
rebooting...
(XEN) Hardware Dom0 shutdown: rebooting machine

Identifying the faulting instruction:

# gunzip /netbsd-XEN3_DOM0.gz
# gdb /netbsd-XEN3_DOM0
(gdb) x/i 0xffffffff806f8fcd
   0xffffffff806f8fcd <vndthread+703>:	idivq  -0x58(%rbp)

A bit of context leading up to the faulting instruction:

   0xffffffff806f8fa5 <vndthread+663>:  callq  0xffffffff806fb143 <VOP_STRATEGY>
   0xffffffff806f8faa <vndthread+668>:	add    %rbx,%r12
   0xffffffff806f8fad <vndthread+671>:	sub    %rbx,%r13
   0xffffffff806f8fb0 <vndthread+674>:	add    %rbx,%r14
   0xffffffff806f8fb3 <vndthread+677>:	movl   $0x0,-0x3c(%rbp)
   0xffffffff806f8fba <vndthread+684>:	mov    0x18(%r15),%rdi
   0xffffffff806f8fbe <vndthread+688>:	mov    $0x20002,%esi
   0xffffffff806f8fc3 <vndthread+693>:	callq  0xffffffff806eeabc <vn_lock>
   0xffffffff806f8fc8 <vndthread+698>:	mov    %r12,%rax
   0xffffffff806f8fcb <vndthread+701>:	cqto   
   0xffffffff806f8fcd <vndthread+703>:	idivq  -0x58(%rbp)

This is reproducible.  Perhaps I got what I deserved doing an unclean
shutdown, but I'm reporting it anyway (as a low priority issue) in
case someone cares.

>How-To-Repeat:

>Fix: