[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |