[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.