This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [RFC] [PATCH] [XEN] [ACM] Enable updating policy on runn

To: Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC] [PATCH] [XEN] [ACM] Enable updating policy on running system
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Fri, 20 Apr 2007 13:31:54 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 20 Apr 2007 10:30:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C24EAD00.DAA1%keir@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

Keir Fraser <keir@xxxxxxxxxxxxx> wrote on 04/20/2007 12:46:40 PM:

> On 20/4/07 17:02, "Stefan Berger" <stefanb@xxxxxxxxxx> wrote:

> >
> > 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?
> While the policy update is happening, a domain could be created with
> a label that is about to be modified or even deleted as part of the
> policy update.

> When a label is associated with a domain, doesn’t that call into ACM
> code? In which case you could define your own locking against that event.

Actually the easiest solution would be to grab the read-lock of the acm policy in do_domctl() before acm_pre_domctl() and release it after acm_post_domctl() or acm_fail_domctl(), which are both at the end of do_domctl(). All of these functions grab and release the read lock individually in some subfunction, but the lock is not being held permanently which is what bothers me for the update.  


>  -- Keir
Xen-devel mailing list