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

Re: [Xen-devel] [RFC PATCH V4 18/18] libxl: add evtchn_extended_allowed flag



On Tue, 2013-03-05 at 13:48 +0000, Ian Jackson wrote:
> Wei Liu writes ("[RFC PATCH V4 18/18] libxl: add evtchn_extended_allowed 
> flag"):
> > Admins can add "evtchn_extended_allowed = 1" in domain config file to enable
> > extended event channel ABI for a domain.
> 
> Why does it default to false ?
> 
> > +=item B<evtchn_extended_allowed=BOOLEAN>
> > +
> > +Flag for allowing domain to use any of the extended event channel ABIs.
> 
> This fails to explain why one might want to disable this.  The only
> reason that comes to my mind is in case it has a security
> vulnerability, an admin who wasn't currently using it could disable
> it.
> 
> Are there other reasons ?
> 

It is not for security reason.

The main concern is that a) extended event channel might use too much
global mapping space in Xen; b) in 3-level ABI's case, normal DomU will
never consume so many event channels.

> This is an odd phrasing given that there is (currently in existence)
> only one extended event channel ABI.  And in the future when we
> introduce more we probably want to be able to disable them
> individually ?
> 

This option in fact was introduced as 3-level event channel ABI only,
the name was evtchn_l3 or something at first. But Jan later suggested
naming it something more generic.

If we are sure that we want to enable extended event channel for all
later ABIs, this option can be restrict to 3-level ABI.


Wei.

> 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®.