mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Yinghai Lu <yinghai@kernel.org>
To: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
	Thomas Gleixner <tglx@linutronix.de>,
	"ebiederm@xmission.com" <ebiederm@xmission.com>,
	"Maciej W. Rozycki" <macro@linux-mips.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [patch] x86, apic: use 0x20 for the IRQ_MOVE_CLEANUP_VECTOR  instead of 0x1f
Date: Fri, 8 Jan 2010 19:07:18 -0800	[thread overview]
Message-ID: <86802c441001081907y7d9c2439x2cb15f8bd7ea6709@mail.gmail.com> (raw)
In-Reply-To: <1263002989.2879.664.camel@sbs-t61.sc.intel.com>

On Fri, Jan 8, 2010 at 6:09 PM, Suresh Siddha <suresh.b.siddha@intel.com> wrote:
> From: Suresh Siddha <suresh.b.siddha@intel.com>
> Subject: x86, apic: use 0x20 for the IRQ_MOVE_CLEANUP_VECTOR instead of 0x1f
>
> After talking to some more folks inside intel (Peter Anvin, Asit Mallick),
> the safest option (for future compatibility etc) seen was to use vector 0x20
> for IRQ_MOVE_CLEANUP_VECTOR instead of using vector 0x1f (which is documented as
> reserved vector in the Intel IA32 manuals).
>
> Also we don't need to reserve the entire privilege level (all 16 vectors in
> the priority bucket that IRQ_MOVE_CLEANUP_VECTOR falls into), as the
> x86 architecture (section 10.9.3 in SDM Vol3a) specifies that with in the
> priority level, the higher the vector number the higher the priority.
> And hence we don't need to reserve the complete priority level 0x20-0x2f for
> the IRQ migration cleanup logic.
>
> So change the IRQ_MOVE_CLEANUP_VECTOR to 0x20 and  allow 0x21-0x2f to be used
> for device interrupts. 0x30-0x3f will be used for ISA interrupts (these
> also can be migrated in the context of IOAPIC and hence need to be at a higher
> priority level than IRQ_MOVE_CLEANUP_VECTOR).
>
> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
> ---
>
> diff --git a/arch/x86/include/asm/irq_vectors.h b/arch/x86/include/asm/irq_vectors.h
> index 585a428..708322a 100644
> --- a/arch/x86/include/asm/irq_vectors.h
> +++ b/arch/x86/include/asm/irq_vectors.h
> @@ -28,19 +28,15 @@
>  #define MCE_VECTOR                     0x12
>
>  /*
> - * IDT vectors usable for external interrupt sources start
> - * at 0x20:
> - * hpa said we can start from 0x1f.
> - *   0x1f is documented as reserved.  However, the ability for the APIC
> - *   to generate vectors starting at 0x10 is documented, as is the
> - *   ability for the CPU to receive any vector number as an interrupt.
> - *   0x1f is used for IRQ_MOVE_CLEANUP_VECTOR since that vector needs
> - *   an entire privilege level (16 vectors) all by itself at a higher
> - *   priority than any actual device vector.  Thus, by placing it in the
> - *   otherwise-unusable 0x10 privilege level, we avoid wasting a full
> - *   16-vector block.
> + * IDT vectors usable for external interrupt sources start at 0x20.
>  */
> -#define FIRST_EXTERNAL_VECTOR          0x1f
> +#define FIRST_EXTERNAL_VECTOR          0x20
> +
> +/*
> + * Reserve the lowest usable vector (and hence lowest priority)  0x20 for
> + * triggering cleanup after irq migration.
> + */
> +#define IRQ_MOVE_CLEANUP_VECTOR                FIRST_EXTERNAL_VECTOR
>
>  #define IA32_SYSCALL_VECTOR            0x80
>  #ifdef CONFIG_X86_32
> @@ -48,17 +44,7 @@
>  #endif
>
>  /*
> - * Reserve the lowest usable priority level 0x10 - 0x1f for triggering
> - * cleanup after irq migration.
> - * this overlaps with the reserved range for cpu exceptions so this
> - * will need to be changed to 0x20 - 0x2f if the last cpu exception is
> - * ever allocated.
> - */
> -
> -#define IRQ_MOVE_CLEANUP_VECTOR                FIRST_EXTERNAL_VECTOR
> -
> -/*
> - * Vectors 0x20-0x2f are used for ISA interrupts.
> + * Vectors 0x30-0x3f are used for ISA interrupts.
>  *   round up to the next 16-vector boundary
>  */
>  #define IRQ0_VECTOR                    ((FIRST_EXTERNAL_VECTOR + 16) & ~15)
> @@ -80,6 +66,12 @@
>  #define IRQ15_VECTOR                   (IRQ0_VECTOR + 15)
>
>  /*
> + * First APIC vector available to drivers: (vectors 0x21-0xee).
> + * (0x80 is the syscall vector, 0x30-0x3f are for ISA)
> + */
> +#define FIRST_DEVICE_VECTOR            (FIRST_EXTERNAL_VECTOR + 1)
> +
> +/*
>  * Special IRQ vectors used by the SMP architecture, 0xf0-0xff
>  *
>  *  some of the following vectors are 'rare', they are merged
> @@ -132,14 +124,6 @@
>  */
>  #define MCE_SELF_VECTOR                        0xeb
>
> -/*
> - * First APIC vector available to drivers: (vectors 0x30-0xee).  We
> - * start allocating at 0x31 to spread out vectors evenly between
> - * priority levels. (0x80 is the syscall vector)
> - */
> -#define FIRST_DEVICE_VECTOR            (IRQ15_VECTOR + 1)
> -#define VECTOR_OFFSET_START            1
> -
>  #define NR_VECTORS                      256
>
>  #define FPU_IRQ                                  13
> diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
> index d5bfa29..5c090a1 100644
> --- a/arch/x86/kernel/apic/io_apic.c
> +++ b/arch/x86/kernel/apic/io_apic.c
> @@ -1162,8 +1162,8 @@ __assign_irq_vector(int irq, struct irq_cfg *cfg, const struct cpumask *mask)
>         * Also, we've got to be careful not to trash gate
>         * 0x80, because int 0x80 is hm, kind of importantish. ;)
>         */
> -       static int current_vector = FIRST_DEVICE_VECTOR + VECTOR_OFFSET_START;
> -       static int current_offset = VECTOR_OFFSET_START % 8;
> +       static int current_vector = FIRST_DEVICE_VECTOR;
> +       static int current_offset = 0;
>        unsigned int old_vector;
>        int cpu, err;
>        cpumask_var_t tmp_mask;
>

looks like it returned to first version i suggested?

http://lkml.org/lkml/2010/1/4/26

maybe we can just kill FIRST_DEVICE_VECTOR...

YH

  parent reply	other threads:[~2010-01-09  3:07 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-09  2:09 Suresh Siddha
2010-01-09  2:19 ` H. Peter Anvin
2010-01-09  2:50   ` Yinghai Lu
2010-01-11 22:53   ` Suresh Siddha
2010-01-11 22:57     ` H. Peter Anvin
2010-01-11 23:10       ` Eric W. Biederman
2010-01-11 23:13         ` H. Peter Anvin
2010-01-12  0:06           ` Suresh Siddha
2010-01-12  0:13             ` H. Peter Anvin
2010-01-12  0:28               ` Eric W. Biederman
2010-01-12  0:36                 ` H. Peter Anvin
2010-01-12  1:52                   ` Eric W. Biederman
2010-01-12  2:17                     ` H. Peter Anvin
2010-01-12  2:27                       ` Eric W. Biederman
2010-01-12 10:25                       ` Alan Cox
2010-01-13 20:36                       ` Eric W. Biederman
2010-01-13 20:38                         ` H. Peter Anvin
2010-01-13 20:53                         ` H. Peter Anvin
2010-01-13 20:58                         ` H. Peter Anvin
2010-01-12  0:42                 ` H. Peter Anvin
2010-01-11 23:00     ` Eric W. Biederman
2010-01-11 23:07       ` H. Peter Anvin
2010-01-09  3:07 ` Yinghai Lu [this message]
2010-01-09  3:20   ` H. Peter Anvin
2010-01-09  3:23 ` H. Peter Anvin

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=86802c441001081907y7d9c2439x2cb15f8bd7ea6709@mail.gmail.com \
    --to=yinghai@kernel.org \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@linux-mips.org \
    --cc=mingo@elte.hu \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    /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

all inboxes | Powered by JetHome®