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
 
   
 

xen-devel

[Xen-devel] Re: [PATCH 2/2] xen/gnt{dev, alloc}: reserve event channels

> That same SELinux category-based isolation mechanism is also a good solution 
> for xen
> qemu-dm processes, although moving qemu to a stubdom provides better 
> isolation since
> SELinux currently cannot talk to XSM to determine what domains a particular 
> qemu-dm 
> process should be able to manipulate.

<nods>
> 
> Only allowing event channels allocated by userspace to be used in gnt* notify 
> is
> a good idea, since there's no reason for userspace to need to manipulate an 
> event
> channel set up by the kernel.
> 
.. snip..
> > 
> > How would that work when the IRQ subsystem (so everything is setup in the 
> > kernel)
> > gets an event? Would the refcount be for that -1.. oh. You would only set
> > the refcnt when the _get/_put calls are made and not when in-kernel calls 
> > to setup
> > IRQs are done?
> > 
> 
> Right. The reference count would be a dual-purpose field indicating if the 
> event
> channel is kernel-internal (value -1) or userspace-visible (reference count > 
> 0).
> New event channels would start out at -1, and evtchn.c would change them to 1.

The tricky bit is going to be with the xen_free_irq which might have to deal 
with kernel
events and grantdev events... oh wait, the event_put is going to decrement it 
and then
call xen_free_irq, so that will come out to be the right number.

Looking forward to the patches! Thanks for doing this work.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>