I have a domain that is sticking around after issuing an xm shutdown on it. xen_changeset Fri Sep 30 10:45:20 2005 +0100 71466686d026 xm list is showing a d flag in the state section, what is this flag? Regards, Ted _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 10/1/05, Ted Kaczmarek <tedkaz@optonline.net> wrote:> I have a domain that is sticking around after issuing an xm shutdown on > it. > > xen_changeset > Fri Sep 30 10:45:20 2005 +0100 71466686d026 > > xm list is showing a d flag in the state section, what is this flag? >I guess "d" = "dead" Hieu. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sat, Oct 01, 2005 at 08:17:40AM -0400, Ted Kaczmarek wrote:> I have a domain that is sticking around after issuing an xm shutdown on > it. > > xen_changeset > Fri Sep 30 10:45:20 2005 +0100 71466686d026 > > xm list is showing a d flag in the state section, what is this flag?"dying". This flag has always been around, but we''ve not been printing it until recently. Previously, such domains may still have been stuck as they are now, but xend will not have printed them as such, or may not have printed them at all. A "dying" domain is one that completed shutdown (be it a halt, reboot, crash, or suspend) and that Xen is trying to destroy. If it cannot destroy it, then that means that someone is holding references to pages that belong to it. For example, if a driver backend fails to die, then the domain will stay around (probably indefinitely). Such an occurrence is a bug. Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ewan Mellor wrote:>A "dying" domain is one that completed shutdown (be it a halt, reboot, crash, >or suspend) and that Xen is trying to destroy. If it cannot destroy it, then >that means that someone is holding references to pages that belong to it. For >example, if a driver backend fails to die, then the domain will stay around >(probably indefinitely). Such an occurrence is a bug. > >One thing to consider is having the drivers destroy the backend devices on a @releaseDomain watch instead of on the front-end path disappearing. @releaseDomain wasn''t available when the drivers were first written so it wasn''t an option then. This means that Xend does not have to be involved at all in device tear-down (except for the higher level stuff when the domain goes away completely). This should more or less solve the zombie domain problem for good. Thoughts? Regards, Anthony Liguori>Ewan. > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sat, Oct 01, 2005 at 02:45:35PM -0500, Anthony Liguori wrote:> One thing to consider is having the drivers destroy the backend devices > on a @releaseDomain watch instead of on the front-end path disappearing.Yes, I think this would make sense. We still need to keep the current behaviour as well, it is needed for hot-unplug of devices. I''d like to see @releaseDomain also pass along the domain id, so that we don''t need to scan all domains in several places. To do this, we should switch the order of the arguments in the watch vectors, allowing us then to pass an arbitrary number of arguments without having to change the interface to support an arbitrary number of arguments[1]. An additional use for this for regular watches could be to pass all the elements of the path which triggered the watch to fire as seperate arguments, reducing the amount of code in the drivers which does string parsing. christian [1] additional arguments are at vec[1] + strlen(vec[1]) + 1 and so on, the callback will need to know how many arguments get passed. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Christian Limpach wrote:>On Sat, Oct 01, 2005 at 02:45:35PM -0500, Anthony Liguori wrote: > > >>One thing to consider is having the drivers destroy the backend devices >>on a @releaseDomain watch instead of on the front-end path disappearing. >> >> > >Yes, I think this would make sense. We still need to keep the current >behaviour as well, it is needed for hot-unplug of devices. > >I''d like to see @releaseDomain also pass along the domain id, so >that we don''t need to scan all domains in several places. >This would be equally useful for @introduceDomain too. It should simplify the code in a number of places (at least in Xend and consoled).>To do this, >we should switch the order of the arguments in the watch vectors, >allowing us then to pass an arbitrary number of arguments without >having to change the interface to support an arbitrary number of >arguments[1]. An additional use for this for regular watches could >be to pass all the elements of the path which triggered the watch to >fire as seperate arguments, reducing the amount of code in the drivers >which does string parsing. > >Is changing the order of token and path really necessary? It''s a considerably simplier change if we maintain the same order. I''ve always thought of the token as an argument so this order makes more sense to me (and I reckon to Rusty since he did it this way to begin with :-)). The only adjustment to the userspace API would be that instead of returning an char *[2] we would return a char *[] that was terminated by a NULL. xenbus needs a little more but it''s not too bad. Regards, Anthony Liguori> christian > >[1] additional arguments are at vec[1] + strlen(vec[1]) + 1 and so on, >the callback will need to know how many arguments get passed. > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sat, Oct 01, 2005 at 08:47:16PM -0500, Anthony Liguori wrote:> >I''d like to see @releaseDomain also pass along the domain id, so > >that we don''t need to scan all domains in several places. > > > This would be equally useful for @introduceDomain too. It should > simplify the code in a number of places (at least in Xend and consoled).Of course.> Is changing the order of token and path really necessary? It''s a > considerably simplier change if we maintain the same order. I''ve always > thought of the token as an argument so this order makes more sense to me > (and I reckon to Rusty since he did it this way to begin with :-)).It''s not absolutely necessary, but makes the code simpler sinceat least within the kernel, we don''t pass the token to the watch callback, only the path and as pointed out in a footnote, you can then get the additional arguments by adding strlen(path)+1 and so on. It''s odd that you would think of the token as an argument since it will always be the same while the node which caused the watch to fire is always different.> The only adjustment to the userspace API would be that instead of > returning an char *[2] we would return a char *[] that was terminated by > a NULL. xenbus needs a little more but it''s not too bad.Wasn''t there a patch which got rid of that array? Also, with a variable number of paths, using an array will become quite complicated since you won''t know how big to allocate the array. Also, I''d like to see something like XS_WATCH_TOKEN and XS_WATCH_PATH as indexes into the array instead of sprinking 0/1 althrough the code, whether we reverse the order or not... christian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Christian Limpach wrote:>>Is changing the order of token and path really necessary? It''s a >>considerably simplier change if we maintain the same order. I''ve always >>thought of the token as an argument so this order makes more sense to me >>(and I reckon to Rusty since he did it this way to begin with :-)). >> >> > >It''s not absolutely necessary, but makes the code simpler sinceat least >within the kernel, we don''t pass the token to the watch callback, only >the path and as pointed out in a footnote, you can then get the additional >arguments by adding strlen(path)+1 and so on. > >So you want to just pass around the path pointer? And rely on people jumping past the end of the string? Yikes :-)>>The only adjustment to the userspace API would be that instead of >>returning an char *[2] we would return a char *[] that was terminated by >>a NULL. xenbus needs a little more but it''s not too bad. >> >> > >Wasn''t there a patch which got rid of that array? >I sent a patch that added a size to the array--Rusty didn''t like it. Rusty suggested changing the userspace interface to something similiar to the kernel interface. The kernel interface doesn''t generalize well--we could hack it to have an additional domid_t * parameter but that kind of sucks.> Also, with a >variable number of paths, using an array will become quite complicated >since you won''t know how big to allocate the array. > >I was thinking of just adding a param to the message that specified the number of entries in the array. That solves that problem.>Also, I''d like to see something like XS_WATCH_TOKEN and XS_WATCH_PATH >as indexes into the array instead of sprinking 0/1 althrough the code, >whether we reverse the order or not... > >Yes, I had thought of this myself. I think having xs_read_watch return the size of the array is the best solution. Returning a zero-terminated array makes it difficult to determine if the watch has a feature (if you know the size, you can check for size < XS_WATCH_* to determine if the watch has a given parameter). I''m going to working something up and submit it. Rusty can weigh in when he gets to Cambridge. Regards, Anthony Liguori> christian > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, Oct 03, 2005 at 05:58:44PM -0500, Anthony Liguori wrote:> >>Is changing the order of token and path really necessary? It''s a > >>considerably simplier change if we maintain the same order. I''ve always > >>thought of the token as an argument so this order makes more sense to me > >>(and I reckon to Rusty since he did it this way to begin with :-)). > > > >It''s not absolutely necessary, but makes the code simpler sinceat least > >within the kernel, we don''t pass the token to the watch callback, only > >the path and as pointed out in a footnote, you can then get the additional > >arguments by adding strlen(path)+1 and so on. > > > So you want to just pass around the path pointer? And rely on people > jumping past the end of the string? Yikes :-)Yes, it''s just as gross as varargs.> The kernel interface doesn''t generalize well--we could hack it to have > an additional domid_t * parameter but that kind of sucks.That would indeed suck and we''re not considering such a specific interface.> I was thinking of just adding a param to the message that specified the > number of entries in the array. That solves that problem.I personally don''t like the array, it''s awkward to allocate, and we''ll still use strlen(path)+1 to fill it in since that''s how data goes across the bus...> >Also, I''d like to see something like XS_WATCH_TOKEN and XS_WATCH_PATH > >as indexes into the array instead of sprinking 0/1 althrough the code, > >whether we reverse the order or not... > > > Yes, I had thought of this myself. I think having xs_read_watch return > the size of the array is the best solution. Returning a zero-terminated > array makes it difficult to determine if the watch has a feature (if you > know the size, you can check for size < XS_WATCH_* to determine if the > watch has a given parameter).So we''d pass &array[1] and the number of entries to the watch callbacks? christian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel