Re: [patch V4 part 5 13/31] x86/irq: Convey vector as argument and not in ptregs

2020-05-11 Thread Lai Jiangshan
Hello On Mon, May 11, 2020 at 10:35 PM Thomas Gleixner wrote: > > Lai, > > Lai Jiangshan writes: > > On Tue, May 5, 2020 at 10:23 PM Thomas Gleixner wrote: > >> +SYM_CODE_START(irq_entries_start) > >> +vector=FIRST_EXTERNAL_VECTOR > >> +.rept (FIRST_SYSTEM_VECTOR -

Re: [patch V4 part 5 13/31] x86/irq: Convey vector as argument and not in ptregs

2020-05-11 Thread Thomas Gleixner
Lai, Lai Jiangshan writes: > On Tue, May 5, 2020 at 10:23 PM Thomas Gleixner wrote: >> +SYM_CODE_START(irq_entries_start) >> +vector=FIRST_EXTERNAL_VECTOR >> +.rept (FIRST_SYSTEM_VECTOR - FIRST_EXTERNAL_VECTOR) >> + UNWIND_HINT_IRET_REGS >> + .byte 0x6a, vector >> +

Re: [patch V4 part 5 13/31] x86/irq: Convey vector as argument and not in ptregs

2020-05-09 Thread Lai Jiangshan
On Tue, May 5, 2020 at 10:23 PM Thomas Gleixner wrote: > +/* > + * ASM code to emit the common vector entry stubs where each stub is > + * packed into 8 bytes. > + * > + * Note, that the 'pushq imm8' is emitted via '.byte 0x6a, vector' because > + * GCC treats the local vector variable as

[patch V4 part 5 13/31] x86/irq: Convey vector as argument and not in ptregs

2020-05-05 Thread Thomas Gleixner
Device interrupts which go through do_IRQ() or the spurious interrupt handler have their separate entry code on 64 bit for no good reason. Both 32 and 64 bit transport the vector number through ORIG_[RE]AX in pt_regs. Further the vector number is forced to fit into an u8 and is complemented and