 
	
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Shadow domains left zombie
 After a hvm+shadow domain dies (either clean shutdown or merciless
destroy), the domain is left in a zombie state with 1 (one) page left
dangling with a single reference.
(XEN) General information for domain 1:
(XEN)     refcnt=1 dying=2 pause_count=1
(XEN)     nr_pages=1 xenheap_pages=0 shared_pages=0 paged_pages=0
dirty_cpus={} max_pages=524544
(XEN)     handle=deadbeef-dead-beef-dead-beef00000001 vm_assist=00000000
(XEN)     paging assistance: shadow refcounts translate external
(XEN) Rangesets belonging to domain 1:
(XEN)     I/O Ports  { }
(XEN)     Interrupts { }
(XEN)     I/O Memory { }
(XEN) Memory pages belonging to domain 1:
(XEN)     DomPage 000000000010698e: caf=00000001, taf=7400000000000000
(XEN)     PoD entries=0 cachesize=0
(XEN) VCPU information and callbacks for domain 1:
(XEN)     VCPU0: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00
dirty_cpus={} cpu_affinity={0-3}
(XEN)     pause_count=1 pause_flags=0
(XEN)     paging assistance: shadowed 4-on-4
(XEN)     No periodic timer
If add a considerable amount of synchronous printk's, sometimes the domain
is not left zombie. There seems to be a race going on here. Due to the
type
information of the page, I believe this is a page that has been shadowed
with a writable map.
I verified the page is not any of the helper rings (qemu, buffered qemu,
store, console) that may get external writeable references.
This happens on win7 guest with or without pv drivers. It happens with or
without shadow optimizations (SHOPT defines). It happens with or without
synchronized p2m lookups (patches just posted).
Hopefully the shadow masters have a better understanding on how to proceed
from here on.
Thanks,
Andres
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
 
 | 
|  | Lists.xenproject.org is hosted with RackSpace, monitoring our |