xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
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

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