5 messages in com.xensource.lists.xen-devel[Xen-devel] Re: [Xen-changelog] New c...| From | Sent On | Attachments |
|---|---|---|
| Anthony Liguori | 30 Aug 2005 10:00 | |
| Christian Limpach | 30 Aug 2005 10:41 | |
| Nivedita Singhvi | 30 Aug 2005 12:19 | |
| Anthony Liguori | 30 Aug 2005 13:16 | |
| Christian Limpach | 31 Aug 2005 01:52 |
| Subject: | [Xen-devel] Re: [Xen-changelog] New console transport and update xenconsoled.![]() |
|---|---|
| From: | Christian Limpach (chri...@gmail.com) |
| Date: | 08/31/2005 01:52:25 AM |
| List: | com.xensource.lists.xen-devel |
On 8/30/05, Anthony Liguori <alig...@us.ibm.com> wrote:
considerably more robust. The virq's aren't always delivered on domain destruction (they are only delivered if a domain crashes or is shutdown).
I see from your latest checkins that you found out what I was talking about.
Yes, I hope that all cases are now covered.
Although, I'm a bit confused at the semantics now. Previously, a DOM_EXC VIRQ was delivered on shutdown or crash. In both circumstances, there's always going to be a destroy that occurs after it (when Xend decides to clean up).
Now it appears that a VIRQ is delivered on shutdown, crash, and then again for destroy? This means that for some domains it's delivered twice (when shutdown or crashed) and some domains it's delivered only once (if they are manually xm destroyed)?
Yes, I guess you can actually get upto 3 VIRQs now when a domain dies: - shutdown/crash - destroy - final cleanup
This is ok though, anybody who listens for the VIRQ needs to handle spurious VIRQs anyway since multiple domains ending at the same time can raise an arbitrary number of VIRQs. The VIRQ only tells you that something has changed.
I think I understand what you guys were trying to do, in consoled today domains are reaped only when 1) they are dead (or dying) and 2) their output buffers are empty. This is to ensure that if you're connected to a console and the domain crashes, you still see all the console output.
For the domain to completely reap (in the new console code), you need to unmap the shared frame. I think the right way to do this is when the domain destroy is detected (in the polling loop), to unmap the shared frame but not actually reap until the above conditions are satisified.
Yeah, at the moment we're still missing the code which lets the output buffer get drained after we detect that a domain has ended.
christian
_______________________________________________ Xen-devel mailing list Xen-...@lists.xensource.com http://lists.xensource.com/xen-devel




