Subject: port-xen/33093: dom0 reboots when destroying domU in non-halted state
To: None <port-xen-maintainer@netbsd.org, gnats-admin@netbsd.org,>
From: None <jdwhite@jdwhite.org>
List: netbsd-bugs
Date: 03/17/2006 04:15:01
>Number:         33093
>Category:       port-xen
>Synopsis:       dom0 reboots when destroying domU in non-halted state
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-xen-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Mar 17 04:15:00 +0000 2006
>Originator:     Jason White
>Release:        NetBSD 3.0
>Organization:
Jason White <jdwhite@jdwhite.org>       Jabber: jdwhite(jabber.org)
http://www.jdwhite.org/~jdwhite                 jason.d.white(gmail.com)
PGP KeyID: 0x5290E477
>Environment:
	
	
System: NetBSD mcp 3.0 NetBSD 3.0 (MCP_DOM0) #1: Wed Mar 15 17:47:56 CST 2006 jdwhite@smeghead:/usr/obj/i386/MCP_DOM0 i386
Architecture: i386
Machine: i386
>Description:
Xen 2.0.  When a domU that's been given access to the UHCI USB controller is 
destroyed (via 'xm destroy <id>') while domU is in a non-halted state, dom0 
locks up for ~10 seconds, then reboots.  Same config file where domU is not 
given access to the UHCI controller does NOT cause dom0 to reboot.

I am unsure if this problem is triggered by giving a domU access to any PCI 
device or just a particular device.

domU config file used at: http://www.jdwhite.org/~jdwhite/netbsd/eclipse.conf

>How-To-Repeat:

Use sample config file from Xen-HOWTO: 
http://www.netbsd.org/Ports/xen/howto.html

Delegeate a pci device to the domU.  My UHCI controller was on bus0, device 
7, func 2.  I added the following to my config file:
pci = [ '0,7,2' ]

# xm create -c /path/to/config

Kernel boots, detects UHCI controller.  Then, destroy the domain:

# xm destroy <id>

Dom0 hangs for a few seconds; reboots.

>Fix:
Shutdown of the domain to bring it to a halted/stopped state is always 
desirable, but not always possible.  If your domU kernel has the debugger 
enabled (and you can get in to it), "reboot 0x8" will halt.  But if domU is 
just hung and can't be halted, "xm destroy" is your only option.

Either way, bad behavior of a domU or destroying a domU, regardless of what 
state that domU is in, should never bring down dom0.


>Unformatted: