[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAObL_7Fq9qHNgu6-+bhagp=_kVnKzx2Kb1BufR2=g6pGeNEPdQ@mail.gmail.com>
Date: Tue, 9 Aug 2011 15:16:50 -0400
From: Andrew Lutomirski <luto@....edu>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: x86@...nel.org, Andi Kleen <andi@...stfloor.org>,
linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
lueckintel@...oo.com, kimwooyoung@...il.com,
Ingo Molnar <mingo@...e.hu>, Borislav Petkov <bp@...en8.de>,
Suresh Siddha <suresh.b.siddha@...el.com>
Subject: Re: [PATCH 1/4] x86-64: Allow emulated vsyscalls from user addresses
On Tue, Aug 9, 2011 at 2:59 PM, H. Peter Anvin <hpa@...or.com> wrote:
> On 08/09/2011 09:27 AM, Andy Lutomirski wrote:
>> *
>> * Vectors 0 ... 31 : system traps and exceptions - hardcoded events
>> - * Vectors 32 ... 127 : device interrupts
>> - * Vector 128 : legacy int80 syscall interface
>> - * Vector 204 : legacy x86_64 vsyscall emulation
>> - * Vectors 129 ... INVALIDATE_TLB_VECTOR_START-1 except 204 : device interrupts
>> + * Vectors 32 ... INVALIDATE_TLB_VECTOR_START-1 : device interrupts, except:
>> + * Vectors 64 ... 66 : legacy x86_64 vsyscall emulation
>> + * Vector 128 : legacy int80 syscall interface
>> * Vectors INVALIDATE_TLB_VECTOR_START ... 255 : special interrupts
>> *
>
> Hi Andy,
>
> Was there a reason to not use the vectors in the 0x2X range?
My general lack of understanding of how all the numbers work, and the
fact that I was waiting for Suresh to answer. I assumed that
/proc/interrupts showed numbers that corresponded to offsets from
FIRST_EXTERNAL_VECTOR, in which case the 0x2X range is no good. I
think that's wrong and they start at 0x40 (maybe?). This comment in
irq_vector.h doesn't help:
/*
* Vectors 0x30-0x3f are used for ISA interrupts.
* round up to the next 16-vector boundary
*/
#define IRQ0_VECTOR ((FIRST_EXTERNAL_VECTOR + 16) & ~15)
If IRQ0_VECTOR is a legacy ISA interrupt, then it's 0x30. So what's
with the rounding? In any case, I don't actually know which vector
irq 18 uses, and I don't know how to dump that information out of
/proc or /sys.
In any case, I won't fix this unless you and/or the rest of the x86
maintainers tell me you prefer this patch to the one that adds a
vsyscall boot parameter.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists