[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/PV: avoid indirect call/thunk in I/O emulation
>>> On 15.02.18 at 17:53, <andrew.cooper3@xxxxxxxxxx> wrote: > On 15/02/18 16:03, Jan Beulich wrote: >> --- a/xen/arch/x86/pv/emul-priv-op.c >> +++ b/xen/arch/x86/pv/emul-priv-op.c >> @@ -73,55 +73,42 @@ void (*pv_post_outb_hook)(unsigned int p >> >> typedef void io_emul_stub_t(struct cpu_user_regs *); >> >> -void __x86_indirect_thunk_rcx(void); >> - >> static io_emul_stub_t *io_emul_stub_setup(struct priv_op_ctxt *ctxt, u8 >> opcode, >> unsigned int port, unsigned int >> bytes) >> { >> struct stubs *this_stubs = &this_cpu(stubs); >> unsigned long stub_va = this_stubs->addr + STUB_BUF_SIZE / 2; >> + signed long disp; > > I'm not in favour of sprinkling 'signed' all over the code base. > > long is already unambiguous, and a far more common construct to encounter. It's this "common" which made me use "signed" here (and in similar places elsewhere) - we still have far too many cases left where plain short/int/long are used when the unsigned variant would actually be better. Hence, _at least_ until those issues are all gone, I very much prefer making explicit when signed quantities are meant. >> bool use_quirk_stub = false; >> >> if ( !ctxt->io_emul_stub ) >> ctxt->io_emul_stub = >> map_domain_page(_mfn(this_stubs->mfn)) + (stub_va & ~PAGE_MASK); >> >> - /* movq $host_to_guest_gpr_switch,%rcx */ >> - ctxt->io_emul_stub[0] = 0x48; >> - ctxt->io_emul_stub[1] = 0xb9; >> - *(void **)&ctxt->io_emul_stub[2] = (void *)host_to_guest_gpr_switch; >> - >> -#ifdef CONFIG_INDIRECT_THUNK >> - /* callq __x86_indirect_thunk_rcx */ >> - ctxt->io_emul_stub[10] = 0xe8; >> - *(int32_t *)&ctxt->io_emul_stub[11] = >> - (long)__x86_indirect_thunk_rcx - (stub_va + 11 + 4); >> -#else >> - /* callq *%rcx */ >> - ctxt->io_emul_stub[10] = 0xff; >> - ctxt->io_emul_stub[11] = 0xd1; >> - /* TODO: untangle ideal_nops from init/livepatch Kconfig options. */ >> - memcpy(&ctxt->io_emul_stub[12], "\x0f\x1f\x00", 3); /* P6_NOP3 */ >> -#endif >> + /* call host_to_guest_gpr_switch */ >> + ctxt->io_emul_stub[0] = 0xe8; >> + disp = (long)host_to_guest_gpr_switch - (stub_va + 1 + 4); > > The 1 in the middle here only aids clarity in the context above, where > it was part of a direct assignment to offset 11 in io_emul_stub[]. > > It is marginal, but in this case, I think stub_va + 5 would be slightly > clearer, as call opcode is obviously at 0, and the length of a call > instruction is 5. Yeah, I wasn't sure which way would be better. Done. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |