Is there now some consensus on how to add security features to XenAPI that
does not cause conflict between XSM and ACM?
Anyway, in response to your main question, I wonder what you actually need
to serialise against? Is it sufficient to just sync against domain creation
-- what if event channels or grant mappings are also occurring during the
policy change? Is there some specific part of domain creation you need to
serialise against?
-- Keir
On 20/4/07 16:58, "Stefan Berger" <stefanb@xxxxxxxxxx> wrote:
> Keir,
>
> as part of the effort to make ACM functionality available via the
> Xen-API, we are adding further functionality to the ACM module in the
> hypervisor. One of these functions is to be able to update a running
> system with a modified policy. The update is happening in several steps:
> relabeling of the domains, testing against the current state of the
> system, committing the changes. During that time it is necessary that no
> other domain be created. I am currently using the domlist_update_lock
> (see DOM_CREATE_LOCK define in the patch) to prevent other domains from
> being added to the system while the update is happening. This is not the
> correct lock to use, though, and I'd rather like to use domctl_lock in
> do_domctl, because that will prevent a domain from being 'created' and
> not just 'added to the list'. So would it be possible to make this lock
> globally available since it is currently a local lock only accessible
> from within do_domctl or are there other ways to achieve this?
>
> Thanks.
> Stefan
>
> Signed-off-by: Stefan Berger <stefanb@xxxxxxxxxx>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home