port-xen/33093: dom0 reboots when domU destroyed in non-shutdown state

[Jason White <jdwhite%jdwhite.org@localhost>]

Greetings,
  I've stumbled across a problem with a domU and an exported PCI USB 
controller with xen 2.0, xentools 2.0.7, dom0 and domU running netbsd 3.0.  
When exporting this device to the domU, if I do a 'xm destroy <id>' and the 
domU isn't halted, dom0 hangs and reboots after about 10 seconds with no 
error messages.

  I discovered this bug while testing a domU kernel to see if it would detect 
the USB controller by booting it with no filesystem.  The kernel found the 
USB controller successfully and since there was no root filesysterm it 
panic()'d and dropped to the debugger.  At that point, I issued a 'xm 
destroy' on the domU.  Just to be clear: I don't typically use xm destroy 
to shut down domains -- this was just a special case.  If I do a "reboot 0x8" 
in the debugger to bring the domU to a shutdown state, all is well.

Still, there may be times when a domU becomes wedged and 'xm destroy' may be 
the only option, so having it not take out dom0 is a good thing.  My DomU Xen 
config file is:

kernel = "/xen/eclipse/netbsd"
memory = 64
name = "eclipse"
cpu = -1
nics = 1
vif = [ 'mac=aa:00:00:50:02:f2, bridge=bridge1' ]
disk = [ 'phy:/dev/raid0f,wd0d,w' ]
root = "/dev/wd0d"
console=9602
pci = [ '0,7,2' ]

If I comment out the "pci =" line domU is destroyed as one would expect 
without taking out dom0, so the misbehavior seems to be tied to the sharing 
of the PCI device.  The kernel config file for the DomU is at: 
http://www.jdwhite.org/~jdwhite/netbsd/ECLIPSE_XENU 
and for Dom0:
http://www.jdwhite.org/~jdwhite/netbsd/MCP_DOM0

Grub config:
default=0
timeout=10
serial --unit=0 --speed=38400 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console
title Xen 2.0 / NetBSD (hda0, serial)
  root(hd0,0)
  kernel (hd0,f)/xen.gz dom0_mem=65536 com1=38400,8n1 
physdev_dom0_hide='(00:07.2)'
  module (hd0,f)/netbsd root=/dev/hda1 ro console=ttyS0

Can anyone replicate this behavior or shed some light on the cause?
Thanks,

-Jason

-- 
Jason White <jdwhite%jdwhite.org@localhost>       Jabber: jdwhite(jabber.org)
http://www.jdwhite.org/~jdwhite                 jason.d.white(gmail.com)
PGP KeyID: 0x5290E477