linux-kernel - Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 04 Nov 2008 14:29:59 +0100
From:	"Alexander van Heukelum" <heukelum@...tmail.fm>
To:	"Ingo Molnar" <mingo@...e.hu>,
	"Alexander van Heukelum" <heukelum@...lshack.com>
Cc:	"LKML" <linux-kernel@...r.kernel.org>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, lguest@...abs.org,
	jeremy@...source.com, "Steven Rostedt" <srostedt@...hat.com>,
	"Cyrill Gorcunov" <gorcunov@...il.com>,
	"Mike Travis" <travis@....com>,
	"Jeremy Fitzhardinge" <jeremy@...p.org>
Subject: Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

On Tue, 4 Nov 2008 13:42:42 +0100, "Ingo Molnar" <mingo@...e.hu> said:
> 
> * Alexander van Heukelum <heukelum@...lshack.com> wrote:
> 
> > Hi all,
> > 
> > An x86 processor handles an interrupt (from an external source, 
> > software generated or due to an exception), depending on the 
> > contents if the IDT. Normally the IDT contains mostly interrupt 
> > gates. Linux points each interrupt gate to a unique function. Some 
> > are specific to some task (handling traps, IPI's, ...), the others 
> > are stubs that push the interrupt number to the stack and jump to 
> > 'common_interrupt'.
> > 
> > This patch removes the need for the stubs.
> 
> hm, the cost would be this new code:
> 
> > +.p2align
> > +ENTRY(maininterrupt)
> >  	RING0_INT_FRAME
> > -vector=0
> > -.rept NR_VECTORS
> > -	ALIGN
> > - .if vector
> > -	CFI_ADJUST_CFA_OFFSET -4
> > - .endif
> > -1:	pushl $~(vector)
> > -	CFI_ADJUST_CFA_OFFSET 4
> > +	push %eax
> > +	push %eax
> > +	mov %cs,%eax
> > +	shr $3,%eax
> > +	and $0xff,%eax
> > +	not %eax
> > +	mov %eax,4(%esp)
> > +	pop %eax
> >  	jmp common_interrupt
> 
> .. which we were able to avoid before. A couple of segment register 
> accesses, shifts, etc to calculate the vector - each of which can be 
> quite costly (especially the segment register access - this is a 
> relatively rare instruction pattern).

The way it is written now is just so I did not have to change
common_interrupt (to keep changes small). All those accesses
so close together will cost some cycles, but much can be avoided
if it is integrated. If the precise content of the stack can be
changed, this could be as simple as "push %cs". Even that can be
delayed, because the content of the cs register will still be
there.

Note that the specialized interrupts (including page fault, etc.)
will not go via this path. As far as I understand now, it is only
the interrupts from external devices that normally go via
common_interrupt. There I think the overhead is really tiny
compared to the rest of the handling of the interrupt.

> I'm not unconvicable, but we need to be conservative here: could you 
> try to measure the full before/after cost of IRQ entry, to the cycle 
> level? I'm curious what the performance impact is.
> 
> Also, this makes life probably a bit harder for Xen, which assumes 
> that the GDT of the guest OS is small-ish. (Jeremy Cc:-ed)

I already had jeremy@...source.com for exactly this reason ;). 

Greetings,
    Alexander

> 	Ingo
-- 
  Alexander van Heukelum
  heukelum@...tmail.fm

-- 
http://www.fastmail.fm - A no graphics, no pop-ups email service

--
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/