[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



Wei Liu writes ("Re: [RFC PATCH V4 18/18] libxl: add evtchn_extended_allowed 
flag"):
> On Tue, 2013-03-05 at 13:48 +0000, Ian Jackson wrote:
> > 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 rather opaque from the documentation as proposed.  Perhaps a
limit on the total number of event channels for a domain would make
more sense ?

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

Well, to an extent we're trying to predict what we might want to
enable/disable in the future.

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

Maybe we want to enable/disable them separately.

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