WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xense-devel

Re: [Xen-devel][Xense-devel][PATCH][XSM][1/4] Xen Security Modules Patch

To: "George S. Coker, II" <gscoker@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel][Xense-devel][PATCH][XSM][1/4] Xen Security Modules Patch
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Fri, 9 Mar 2007 17:01:34 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir@xxxxxxxxxxxxx>, xense-devel@xxxxxxxxxxxxxxxxxxx, xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 09 Mar 2007 14:00:50 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1173470696.24363.29.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
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

xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 03/09/2007 03:04:56 PM:

> On Fri, 2007-03-09 at 12:51 -0500, Stefan Berger wrote:
> >
> > xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 03/09/2007 11:55:11 AM:
> >
> > > On Fri, 2007-03-09 at 09:43 +0000, Keir Fraser wrote:
> > > > On 8/3/07 19:58, "George S. Coker, II" <gscoker@xxxxxxxxxxxxxx>
> > wrote:
> > > >
> > >
> > > > > To achieve a very light-weight
> > > > > domain, one would like to remove as much functionality from that
> > domain
> > > > > as possible, to include the interrupt handler.  Instead, there
> > would
> > > > > exist a light-weight domain interrupt handler domain that is
> > responsible
> > > > > for this functionality.  These interrupts would manifest as
> > interdomain
> > > > > channels; however, the ipi mechanism remains unless a hook
> > exists to
> > > > > block this code path.  Likewise, the light-weight domains
> > wouldn't be
> > > > > able to close their channels arbitrarily, and require a check on
> > close
> > > > > as well.
> > > >
> > > > I think this sounds like a microkernel-style 'interrupt server'?
> > Why would
> > > > you want that? And if you did have it, why would you care about
> > the clients
> > > > of this server closing their ends of interdomain event channels?
> > > >
> > > Fair enough.  I'll remove the close check, although we will still
> > need a
> > > hook in the close code path for cleanup.
> > >  
> >
> > There's also a mediation in evtchn_init() [.evtchn_init]. evtchn_init
> > () is called from one since place only and that is domain_create(),
> > which in turn is behind the xsm_createdomain() mediation call
> > [.createdomain]. I suppose it would be enough to guard the creation of
> > a domain by the xsm_createdomain() hook only, no?
> >
> In light of the other comments, you are correct.


Why is there mediation in evtchn_reset [.evtchn_reset]? It looks like the code tries to only close an event channel if necessary. I suppose that once you have been allowed to open an event channel you should be able to reset (close) it.

   Stefan

>
> >    Stefan
> >
> >
> > > >  -- Keir
> > >
> > >
> > > _______________________________________________
> > > 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>