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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Mar 05, 2013 at 05:56:12PM +0000, David Vrabel wrote:
> On 05/03/13 17:51, Wei Liu wrote:
> > On Tue, Mar 05, 2013 at 05:38:54PM +0000, Ian Jackson wrote:
> >> 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 ?
> > 
> > I will improve the documentation. But putting a limit on total number of
> > event channels for a domain for now is not what I expect, because a)
> > having limit on 2/3-level event channels brings no significant
> > improvement, b) the infrastructure to notify a guest about its limit
> > doesn't exists.
> 
> The user-visible limit option could be toolstack only.  i.e., internally
> libxc decides a limit of > 4096 (> 1024 for a 32-bit x86 guest) requires
> enabling extended event channels.

True. This can also benefit future ABIs. 

But I think I should add the decision making logic in libxl, not libxc.


Wei.

> 
> David

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