Re: [Xen-changelog] New console transport and update xenconsoled.

[Christian Limpach <christian.limpach@gmail.com>]

On 8/30/05, Anthony Liguori <aliguori@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