From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [PATCH 16/16] xen/events: use the FIFO-based ABI if available
Date: Wed, 16 Oct 2013 09:26:43 -0400 [thread overview]
Message-ID: <525E9413.70907@oracle.com> (raw)
In-Reply-To: <525E607D.8040900@citrix.com>
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
next prev parent reply other threads:[~2013-10-16 13:26 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-08 12:48 [PATCHv6 00/16] Linux: FIFO-based event channel ABI David Vrabel
2013-10-08 12:49 ` [PATCH 01/16] xen/events: refactor retrigger_dynirq() and resend_irq_on_evtchn() David Vrabel
2013-10-14 15:59 ` Boris Ostrovsky
2013-10-14 16:35 ` David Vrabel
2013-10-08 12:49 ` [PATCH 02/16] xen/events: remove unnecessary init_evtchn_cpu_bindings() David Vrabel
2013-10-08 12:49 ` [PATCH 03/16] xen/events: introduce test_and_set_mask David Vrabel
2013-10-08 12:49 ` [PATCH 04/16] xen/events: replace raw bit ops with functions David Vrabel
2013-10-14 16:30 ` Boris Ostrovsky
2013-10-14 16:43 ` David Vrabel
2013-10-08 12:49 ` [PATCH 05/16] xen/events: move drivers/xen/events.c into drivers/xen/events/ David Vrabel
2013-10-08 12:49 ` [PATCH 06/16] xen/events: move 2-level specific code into its own file David Vrabel
2013-10-14 16:50 ` Boris Ostrovsky
2013-10-14 16:53 ` David Vrabel
2013-10-08 12:49 ` [PATCH 07/16] xen/events: add struct evtchn_ops for the low-level port operations David Vrabel
2013-10-08 12:49 ` [PATCH 08/16] xen/events: allow setup of irq_info to fail David Vrabel
2013-10-14 17:26 ` Boris Ostrovsky
2013-10-15 19:20 ` David Vrabel
2013-10-08 12:49 ` [PATCH 09/16] xen/events: add a evtchn_op for port setup David Vrabel
2013-10-08 12:49 ` [PATCH 10/16] xen/events: Refactor evtchn_to_irq array to be dynamically allocated David Vrabel
2013-10-14 17:52 ` Boris Ostrovsky
2013-10-15 18:58 ` David Vrabel
2013-10-08 12:49 ` [PATCH 11/16] xen/events: add xen_evtchn_mask_all() David Vrabel
2013-10-08 12:49 ` [PATCH 12/16] xen/evtchn: support more than 4096 ports David Vrabel
2013-10-14 18:06 ` Boris Ostrovsky
2013-10-08 12:49 ` [PATCH 13/16] xen/events: Add the hypervisor interface for the FIFO-based event channels David Vrabel
2013-10-08 12:49 ` [PATCH 14/16] xen/events: allow event channel priority to be set David Vrabel
2013-10-08 12:49 ` [PATCH 15/16] xen/x86: set VIRQ_TIMER priority to maximum David Vrabel
2013-10-08 12:49 ` [PATCH 16/16] xen/events: use the FIFO-based ABI if available David Vrabel
2013-10-14 19:30 ` Boris Ostrovsky
2013-10-15 18:58 ` David Vrabel
2013-10-15 20:39 ` Boris Ostrovsky
2013-10-16 9:46 ` David Vrabel
2013-10-16 13:26 ` Boris Ostrovsky [this message]
2013-10-16 13:49 ` David Vrabel
2013-10-14 13:41 ` [PATCHv6 00/16] Linux: FIFO-based event channel ABI David Vrabel
2013-10-16 15:19 ` Ian Campbell
2013-10-16 15:36 ` David Vrabel
2013-10-16 15:38 ` Ian Jackson
-- strict thread matches above, loose matches on Subject: below --
2013-11-11 16:12 [PATCHv9 " David Vrabel
2013-11-11 16:13 ` [PATCH 16/16] xen/events: use the FIFO-based ABI if available David Vrabel
2013-10-31 15:09 [PATCHv8 00/16] Linux: FIFO-based event channel ABI David Vrabel
2013-10-31 15:09 ` [PATCH 16/16] xen/events: use the FIFO-based ABI if available David Vrabel
2013-10-18 14:23 [PATCHv7 00/16] Linux: FIFO-based event channel ABI David Vrabel
2013-10-18 14:23 ` [PATCH 16/16] xen/events: use the FIFO-based ABI if available David Vrabel
2013-10-02 17:14 [PATCHv5 00/16] Linux: FIFO-based event channel ABI David Vrabel
2013-10-02 17:15 ` [PATCH 16/16] xen/events: use the FIFO-based ABI if available David Vrabel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=525E9413.70907@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=jbeulich@suse.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).