This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [Xen-changelog] New console transport and update xencons

To: Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Subject: [Xen-devel] Re: [Xen-changelog] New console transport and update xenconsoled.
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Tue, 30 Aug 2005 15:17:14 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Robert Read <robert@xxxxxxxxxxxxx>
Delivery-date: Tue, 30 Aug 2005 20:17:20 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20050830174144.GT24659@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <E1EA8qJ-0002Zl-23@xxxxxxxxxxxxxxxxxxxxx> <431490D4.20108@xxxxxxxxxx> <20050830174144.GT24659@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
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..


Anthony Liguori


Xen-devel mailing list