From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH 16/16] xen/events: use the FIFO-based ABI if available Date: Wed, 16 Oct 2013 09:26:43 -0400 Message-ID: <525E9413.70907@oracle.com> References: <1381236555-27493-1-git-send-email-david.vrabel@citrix.com> <1381236555-27493-17-git-send-email-david.vrabel@citrix.com> <525C4663.70907@oracle.com> <525D906C.5080401@citrix.com> <525DA7E7.8020009@oracle.com> <525E607D.8040900@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <525E607D.8040900@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: David Vrabel Cc: Jan Beulich , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 10/16/2013 05:46 AM, David Vrabel wrote: > On 15/10/13 21:39, Boris Ostrovsky wrote: >> On 10/15/2013 02:58 PM, David Vrabel wrote: >>> On 14/10/13 20:30, Boris Ostrovsky wrote: >>>> On 10/08/2013 08:49 AM, David Vrabel wrote: >>>>> @@ -1636,7 +1637,13 @@ void xen_callback_vector(void) {} >>>>> void __init xen_init_IRQ(void) >>>>> { >>>>> - xen_evtchn_2l_init(); >>>>> + int ret; >>>>> + >>>>> + ret = xen_evtchn_fifo_init(); >>>>> + if (ret < 0) { >>>>> + printk(KERN_INFO "xen: falling back to n-level event >>>>> channels"); >>>>> + xen_evtchn_2l_init(); >>>>> + } >>>> Should we provide users with ability to choose which mechanism to use? >>>> Is there any advantage in staying with 2-level? Stability, I guess, >>>> would be one. >>> If someone can demonstrate a use case where 2-level is better then we >>> could consider an option. I don't think we want options for new >>> software features just because they might be buggy. >> I think we should always try to have a way to force old behavior when a >> new feature is introduced. If a user discovers a bug we don't want them >> to wait for a fix when a simpler solution is possible. I can see that >> having this option in the kernel may be a bit too much but is there at >> least an option to force 2-level in the hypervisor? > The majority of the risk in this series is the refactoring patches and > not the new ABI code so an option to disable it wouldn't really help. > > Also, if we are not confidant that a feature is production ready that we > need knobs to turn it off then we shouldn't merge it. I disagree. If this were the case then hardware wouldn't have chicken bits and there wouldn't exist half of "no*" options to kernel, for example. We are introducing a rewrite of a critical component of the system. It has bugs (by definition) and there should be a way to fall back to an implementation that presumably has fewer bugs. -boris