All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH] x86: clean up __io_apic_eoi()
Date: Mon, 14 Nov 2011 14:07:35 +0000	[thread overview]
Message-ID: <4EC120A7.3080600@citrix.com> (raw)
In-Reply-To: <4EC0E88F0200007800060B37@nat28.tlf.novell.com>



On 14/11/11 09:08, Jan Beulich wrote:
>>>> On 11.11.11 at 17:49, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 11/11/11 16:07, Jan Beulich wrote:
>>> Irrespective of the IO-APIC vector sharing suppression patch just sent
>>> the logic in this function needs to iterate over all RTEs, since
>>> multiple pins within an IO-APIC may still use the same vector.
>> Why?  The whole point of preventing vector sharing for IO-APICs is to
>> prevent two or more RTEs referencing the same vector.
> If that was really the case on *all* systems, then we wouldn't need
> the chains of IRQs hanging off irq_2_pin[] entries. Obviously there are
> or have been or could theoretically be systems that do make use of this.
>
> BUT again after some more thinking about this over the weekend
> (and after fixing the issue pointed out in the other response regarding
> the other patch) I think we can actually convert the function to
> behave the way you intended it to after dealing with the vector
> sharing issue: The call sites are then only __eoi_IO_APIC_irq() (which
> already traverses the chain from irq_2_pin[]) and clear_IO_APIC_pin()
> (which explicitly wants to deal with just a single (apic, pin) tuple, the
> uses in the timer interrupt related boot time code having been bogus in
> this respect even before your original change to the EOI logic, as they
> imply that no other (apic, pin) tuple also represents the timer IRQ).
>
> Jan
>

Ah yes.  I was silly and had not considered that possibility. 
Realistically, I doubt there are many boxes still around which have
shared ISA interrupts, but we should deal with the case.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com

  reply	other threads:[~2011-11-14 14:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-11 16:07 [PATCH] x86: clean up __io_apic_eoi() Jan Beulich
2011-11-11 16:49 ` Andrew Cooper
2011-11-14  9:08   ` Jan Beulich
2011-11-14 14:07     ` Andrew Cooper [this message]
2011-11-14 14:14       ` Jan Beulich

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=4EC120A7.3080600@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=xen-devel@lists.xensource.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.