From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Xen-changelog] New console transport and update xenconsoled. Date: Tue, 30 Aug 2005 15:17:14 -0500 Message-ID: <4314BECA.5070104@us.ibm.com> References: <431490D4.20108@us.ibm.com> <20050830174144.GT24659@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20050830174144.GT24659@cl.cam.ac.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Christian Limpach Cc: xen-devel@lists.xensource.com, Robert Read List-Id: xen-devel@lists.xenproject.org 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 > > > >