[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating 3-level event channel pages



On Mon, 2013-02-04 at 13:59 +0000, Wei Liu wrote:
> On Mon, 2013-02-04 at 13:54 +0000, Ian Campbell wrote:
> > On Mon, 2013-02-04 at 13:51 +0000, Wei Liu wrote:
> > > On Mon, 2013-02-04 at 13:47 +0000, Ian Campbell wrote:
> > > > On Mon, 2013-02-04 at 13:45 +0000, Wei Liu wrote:
> > > > 
> > > > > /*
> > > > >  * Note to 3-level event channel users:
> > > > >  * Only enable 3-level event channel for Dom0 or driver domains, 
> > > > > because
> > > > >  * 3-level event channels consumes (16 + nr_vcpus pages) global 
> > > > > mapping
> > > > >  * area in Xen.
> > > > >  */
> > > > 
> > > > Can this be enforced by the system administrator?
> > > > 
> > > 
> > > Knowing a domain is Dom0 is easy, but is it possible to know a domain is
> > > driver domain?
> > 
> > The admin knows, at the very least they need to have a manual override
> > (or maybe this should even default off for non-dom0)
> > 
> 
> Do you mean maintaining white list in Xen or adding options in guest
> kernel?

I mean that it should be a property of the domain (i.e. a flag in struct
domain or whatever) whether they can use 3-levels and this should be
settable by the host administrator when they build the guest.

> I already have that in my kernel patch series - only enable
> 3-level event channel for Dom0.

Imagine I am a malicious user of you cloud service, I could potentially
create dozens of guests using kernels which forcibly try to use 3-level
evtchns and suck up loads of host RAM.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.