"virtual cluster" debug support

"virtual cluster" debug support

[Kip Macy]

To my local tree I'm about to commit support for the notion of a
"virtual cluster" for debugging purposes. The idea is that when one
node (domain) in a cluster hits a breakpoint, all the other nodes are
paused so that the first node doesn't get voted out of the quorum. I'd
be very surprised if there are other potential users for this
functionality, but I'm asking just in case.

The current implementation is done in such a way as to minimally
perturb the existing interfaces to make it easy to carry it as an
outside patch indefinitely. However, if others might use, it could be
implemented more cleanly.

   -Kip


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

RE: "virtual cluster" debug support

[Ian Pratt]

> To my local tree I'm about to commit support for the notion of a
> "virtual cluster" for debugging purposes. The idea is that when one
> node (domain) in a cluster hits a breakpoint, all the other nodes are
> paused so that the first node doesn't get voted out of the quorum. I'd
> be very surprised if there are other potential users for this
> functionality, but I'm asking just in case.
> 
> The current implementation is done in such a way as to minimally
> perturb the existing interfaces to make it easy to carry it as an
> outside patch indefinitely. However, if others might use, it could be
> implemented more cleanly.

I guess the 'nice' way of doing this would be to have a notion of
'domain groups', akin to process groups. This would be pretty trivial to
hack in: 
 * add a group_id integer to the domain struct. 0 is special = not
grouped
 * add a domains struct * to create a circular list of domains in same
group
 * add a dom0_op to set the group of a domain (scan domain list, adjust
circular list)
 * on break point follow circular list issuing pause_domain(d)

Ian


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

Re: "virtual cluster" debug support

[Kip Macy]

That is almost exactly what I've done, except I didn't add a group id
and I used pad0 builddomain for a partner id (yes I know it is gross)
so the group would get set at buildtime.

And of course one cannot set domain 0 as a partner.
 

       -Kip


> I guess the 'nice' way of doing this would be to have a notion of
> 'domain groups', akin to process groups. This would be pretty trivial to
> hack in:
>  * add a group_id integer to the domain struct. 0 is special = not
> grouped
>  * add a domains struct * to create a circular list of domains in same
> group
>  * add a dom0_op to set the group of a domain (scan domain list, adjust
> circular list)
>  * on break point follow circular list issuing pause_domain(d)
> 
> Ian
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: "virtual cluster" debug support

[Kip Macy]

Please review the following diff. I will follow up with a signed off
patch with the required fixes.

http://www.fsmware.com/xenofreebsd/gdb/050318/clusterbkpt.diff

                  -Kip

On Fri, 18 Mar 2005 00:35:10 -0000, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:
> > To my local tree I'm about to commit support for the notion of a
> > "virtual cluster" for debugging purposes. The idea is that when one
> > node (domain) in a cluster hits a breakpoint, all the other nodes are
> > paused so that the first node doesn't get voted out of the quorum. I'd
> > be very surprised if there are other potential users for this
> > functionality, but I'm asking just in case.
> >
> > The current implementation is done in such a way as to minimally
> > perturb the existing interfaces to make it easy to carry it as an
> > outside patch indefinitely. However, if others might use, it could be
> > implemented more cleanly.
> 
> I guess the 'nice' way of doing this would be to have a notion of
> 'domain groups', akin to process groups. This would be pretty trivial to
> hack in:
>  * add a group_id integer to the domain struct. 0 is special = not
> grouped
>  * add a domains struct * to create a circular list of domains in same
> group
>  * add a dom0_op to set the group of a domain (scan domain list, adjust
> circular list)
>  * on break point follow circular list issuing pause_domain(d)
> 
> Ian
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

RE: "virtual cluster" debug support

[Ian Pratt]

> Please review the following diff. I will follow up with a signed off
> patch with the required fixes.
> 
> http://www.fsmware.com/xenofreebsd/gdb/050318/clusterbkpt.diff

Kip,

I think it would definitely be better to have a separate dom0 op to set
the domain group rather having it as part of the create operation. It's
something that you might want to change after the domain's creation
(though create will fill in a default of groupid = domid).

I'm not keen on the proliferation of dom0 ops, and I expect we'll merge
a number of them into a 'get/set domain parameter' operation at some
point, but for the moment, I think the best soloution is adding a
DOM0_SETDOMAINGROUP. 

Thanks,
Ian



> 
>                   -Kip
> 
> On Fri, 18 Mar 2005 00:35:10 -0000, Ian Pratt 
> <m+Ian.Pratt@cl.cam.ac.uk> wrote:
> > > To my local tree I'm about to commit support for the notion of a
> > > "virtual cluster" for debugging purposes. The idea is 
> that when one
> > > node (domain) in a cluster hits a breakpoint, all the 
> other nodes are
> > > paused so that the first node doesn't get voted out of 
> the quorum. I'd
> > > be very surprised if there are other potential users for this
> > > functionality, but I'm asking just in case.
> > >
> > > The current implementation is done in such a way as to minimally
> > > perturb the existing interfaces to make it easy to carry it as an
> > > outside patch indefinitely. However, if others might use, 
> it could be
> > > implemented more cleanly.
> > 
> > I guess the 'nice' way of doing this would be to have a notion of
> > 'domain groups', akin to process groups. This would be 
> pretty trivial to
> > hack in:
> >  * add a group_id integer to the domain struct. 0 is special = not
> > grouped
> >  * add a domains struct * to create a circular list of 
> domains in same
> > group
> >  * add a dom0_op to set the group of a domain (scan domain 
> list, adjust
> > circular list)
> >  * on break point follow circular list issuing pause_domain(d)
> > 
> > Ian
> >
> 


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

Re: "virtual cluster" debug support

[Kip Macy]

> (though create will fill in a default of groupid = domid).

That restriction is only a current limitation of the tools. I simply
haven't taken the time to set the option at runtime.

> I'm not keen on the proliferation of dom0 ops, and I expect we'll merge
> a number of them into a 'get/set domain parameter' 
operation at some

What is wrong with {GET/SET}DOMAININFO? These can be done at run-time.
If you look, you'll see that I explicitly handle the case of removing
a domain from an existing group before adding it to another.

> point, but for the moment, I think the best soloution is adding a
> DOM0_SETDOMAINGROUP.

I'm perfectly happy to do that, but I'd like to know why SETDOMAININFO
doesn't fit the bill.

I would also appreciate feedback on the correctness of the locking.

Thanks.

        -Kip


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

RE: "virtual cluster" debug support

[Ian Pratt]

 

> What is wrong with {GET/SET}DOMAININFO? These can be done at run-time.
> If you look, you'll see that I explicitly handle the case of removing
> a domain from an existing group before adding it to another.

GET/SETDOMAININFO is used for get/setting the CPU execution state. The
IN parameteres are used for selecting an execution context, and adding a
groupid parameter to them is certainly very odd.

I don't think the patch should touch xc_linux_build either -- setting
the groupid is a generic thing that the tools can do after creating the
domain.

The rest looks fine.
[When the domain is first created, groupid should be set to domid. When
choosing a domid for a new domain, avoid picking domid's that are still
in use as a groupid by another domain.]

> I would also appreciate feedback on the correctness of the locking.

Locking looks OK to me, but I'm only reading the patch at the moment --
I always do a final look through after applying.

Ian


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

Re: "virtual cluster" debug support

[Kip Macy]

> GET/SETDOMAININFO is used for get/setting the CPU execution state. The
> IN parameteres are used for selecting an execution context, and adding a
> groupid parameter to them is certainly very odd.

Good point. That would lead me to believe that they are slightly
misnamed. Wouldn't GET/SETDOMAINCONTEXT be more apt?

> I don't think the patch should touch xc_linux_build either -- setting
> the groupid is a generic thing that the tools can do after creating the
> domain.

Fair enough. I can easily get carried away with what is most expedient
for me. Which is why I sent a diff and not a patch. I knew it would
come under the knife.

When I check in a file, how do I make sure it stays executable?

      -Kip


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

RE: "virtual cluster" debug support

[Ian Pratt]

 
> > GET/SETDOMAININFO is used for get/setting the CPU execution 
> state. The
> > IN parameteres are used for selecting an execution context, 
> and adding a
> > groupid parameter to them is certainly very odd.
> 
> Good point. That would lead me to believe that they are slightly
> misnamed. Wouldn't GET/SETDOMAINCONTEXT be more apt?

Indeed it would. A spring clean of the dom0 interface is certainly in
order. The 'forcing factor' for this will be when we move to more
fine-grained privilege capabilities. Even the interface name dom0_op is
no longer actually strictly correct... 

> When I check in a file, how do I make sure it stays executable?

bk chmod +x foo.py

Ian


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click