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

[Anthony Liguori <aliguori@us.ibm.com>]

Christian Limpach wrote:

>On Tue, Aug 30, 2005 at 12:01:08PM -0500, Anthony Liguori wrote:
>  
>
>>Why are we listening for virq?  The polling method used before is 
>>considerably more robust.  The virq's aren't always delivered on domain 
>>destruction (they are only delivered if a domain crashes or is shutdown).
>>    
>>
>
>That would be a bug then, when does it happen?
>  
>
I see from your latest checkins that you found out what I was talking about.

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)?

This is why I've not treated this as a bug previously.  I don't think 
the new behavior is much more useful.

>>Moreover, I thought the overriding goal of this was to get rid of xcs?  
>>Why are we still using it?
>>    
>>
>
>Because we haven't switched virq delivery over to use the store.
>  
>
With VM-Tools and consoled, I've convinced myself that polling is the 
right way to go for detecting events.  It's a bunch more code but it's 
got a lot of advantages.

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.

There's a bit of a memory leak here (sort of) if noone ever reads the 
final data for a domain.  I've been thinking that having a timeout is 
the right way to handle that.  That's just not been all that much of a 
priority.

>>Also, there's a number of errors that this code introduces (changing 
>>things to use asprintf and not checking for OOM conditions).  It would 
>>have been nice if this went to the list first so we could comment on it.
>>I'll submit some cleanup patches later today...
>>    
>>
>
>Thanks, looking forward to those patches!
>  
>
Writing them as we speak..

Regards,

Anthony Liguori

>    christian
>
>
>  
>