Re: [PATCH/RFC] Move entry_64.S register saving out of the macros

["H. Peter Anvin" <hpa@zytor.com>]

Alexander van Heukelum wrote:
> Hi all,
> 
> Here is a combined patch that moves "save_args" out-of-line for
> the interrupt macro and moves "error_entry" mostly out-of-line
> for the zeroentry and errorentry macros.
> 
> The save_args function becomes really straightforward and easy
> to understand, with the possible exception of the stack switch
> code, which now needs to copy the return address of to the
> calling function. Normal interrupts arrive with ((~vector)-0x80)
> on the stack, which gets adjusted in common_interrupt:
> 
> <common_interrupt>:
> (5)  addq   $0xffffffffffffff80,(%rsp)		/* -> ~(vector) */
> (4)  sub    $0x50,%rsp				/* space for registers */
> (5)  callq  ffffffff80211290 <save_args>
> (5)  callq  ffffffff80214290 <do_IRQ>
> <ret_from_intr>:
>      ...
> 
> An apic interrupt stub now look like this:
> 
> <thermal_interrupt>:
> (5)  pushq  $0xffffffffffffff05			/* ~(vector) */
> (4)  sub    $0x50,%rsp				/* space for registers */
> (5)  callq  ffffffff80211290 <save_args>
> (5)  callq  ffffffff80212b8f <smp_thermal_interrupt>
> (5)  jmpq   ffffffff80211f93 <ret_from_intr>
> 

Sorry, I'm away on a trip at the moment, so sorry for the delayed feedback.

First of all, if we're going to go through common code here, we should 
do the vector number adjustment in save_args and be able to use the 
short form of pushq in the common case.

What isn't clear to me is if we should just push a target field to the 
stack and then do an indirect call.  That way we can do save_args and 
ret_from_intr inline, but at the expense of an indirect call which will 
not necessarily speculate cleanly.

All of this qualify as "tweaking", which means we need to be very 
careful so we don't end up burning more performance than we gain, but 
all in all, I think this is a good idea.

	-hpa