xm list d flag?

xm list d flag?

[Ted Kaczmarek]

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

Re: xm list d flag?

[NAHieu]

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.

Re: xm list d flag?

[Ewan Mellor]

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.

Re: xm list d flag?

[Anthony Liguori]

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

Re: xm list d flag?

[Christian Limpach]

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.

Re: xm list d flag?

[Anthony Liguori]

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.
>
>
>  
>

Re: xm list d flag?

[Christian Limpach]

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

Re: xm list d flag?

[Anthony Liguori]

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

Re: xm list d flag?

[Christian Limpach]

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