| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [Xen-changelog] New console transport and update xencons
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home