Re: [PATCH 0/8] Domain Groups: Introduction

[Chris <hap10@tycho.ncsc.mil>]

Keir Fraser wrote:
> On 20/2/07 23:01, "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> wrote:
>> It's certainly useful to be able to pause groups of domains e.g. when
>> debugging cluster filesystems etc.
> 
> That doesn't require Xen to be aware of the groups. If the domains need to
> be paused as instantaneously as possible then a multicall of domctls may
> well suffice.

Using multicall is a different, but reasonable approach to operate on a
set of domains with a similar level of atomicity to what's currently in
the domgrps patch.  That said, I stopped well short of absolute
atomicity in the domgrps implementation to avoid being offensively
intrusive.  By extending the domgrps approach to work with the scheduler
it's possible to provide group operations with a level of atomicity not
achievable from the current mutlicall implementation.  However, deciding
what degree of atomicity is necessary falls into what I believe should
be a separate (but important) discussion.

> I think we need to decide whether the benefits of supporting
> this concept down to the hypervisor make it worth adding significant
> extra management code at ring 0.

This is the part of the discussion I most wanted to have.  Whatever
mechanism you use to operate on a set of domains, life is better when
the hypervisor is aware of the group abstraction.  With a group-aware
hypervisor there is a robustness gain because even if the entire control
stack falls over, group data can be re-populated from the hypervisor.
Also, having group data managed in the hypervisor provides a level of
separation between the group policy in the control stack and the
management mechanism in the VMM.  However, most interesting are the
opportunities gained with integration of XSM/ACM.  There are new
opportunities for isolation of domain groups, dom0 decomposition, and
more powerful primitives for the XSM policy language.  We can get into
more detail here if this high-level overview doesn't do enough to
justify the ~650 lines (including comments and whitespace) of additional
ring 0 code.

> There may be a more compelling argument for groups as a security
> abstraction, but I think we need to stand back and work out the overall
> story there with XSM and all.

Although both Domain Groups and XSM can stand on their own merits we've
been aiming for integration of two from the start.  The integration is
planned, but not yet started because we want to incorporate community
feedback on each project individually.  Improvements are in progress for
XSM and I'm certainly willing to discuss revisions for Domain Groups.

-Chris