Re: [Xen-devel] Zombie domains

[David Lie <lie@xxxxxxxxxxxxxxxx>]

This was done on the testing release.  There are some small changes to
the underlying Xen hypervisor that we've made so it's not as straight
forward to just try it on the unstable release (I'm working on a port of
our OSDI work from Xen 2.0 to Xen 3.0).

I'll look into it, but it is not causing any huge problems for me right
now.  Another thing is I noticed is the flags field also seems a bit
suspicious.  Am I interpreting that the value "6" correctly to mean that
the domain is both dying and being debugged?  How would it get into the
state that it thinks it is being debugged?

-DL

Ian Pratt wrote:
>> I'm using the grant table to map a shared frame between two domains.
>> Domain 1 shares the frame, and Domain 2 maps it into it's address
> space.
>> I then make sure Domain 2 unmaps the frame, and releases all event
>> channels, etc... before shutting down.  Domain 2 always remains as a
>> zombie though when I do xm list.  If I dump the domain info in the Xen
>> console, I get this information for the zombie domain:
>>
>> (XEN) General information for domain 12:
>> (XEN)     flags=6 refcnt=1 nr_pages=0 xenheap_pages=0 dirty_cpus={}
>> (XEN)     handle=f4a55907-26db-d7c3-f6a7-392637013289
>> (XEN) Rangesets belonging to domain 12:
>> (XEN)     Interrupts { }
>> (XEN)     I/O Memory { }
>> (XEN)     I/O Ports  { }
>> (XEN) Memory pages belonging to domain 12:
>> (XEN) VCPU information and callbacks for domain 12:
>> (XEN)     VCPU0: CPU0 [has=F] flags=10 upcall_pend = 01, upcall_mask =
>> 00 dirty}(XEN)     Notifying guest (virq 1, port 0, stat 0/0/-1)
> 
> The usual region for zombie domains is other domains having its memory
> mapped, but not in this case: nr_pages=0
> 
>> Unfortunately, these fields do not mean very much to me.  What does
>> upcall_pend mean?  
> 
> There's an event pending for the domain. Not a big deal.
> 
>> Sometimes this field is 01, sometimes it's 00.  What
>> about refcnt?  
> 
> Something has a reference to the domain structure, hence preventing it
> from being freed. This must be a xen bug. Your OS is likely provoking an
> error path that is missing a 'put'.   
> 
> Have you tried this with latest -unstable?
> 
> Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel