Re: [Xen-devel] [PATCH 2/4] x86emul: move stubs off the stack

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 19.05.15 at 19:33, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 18/05/15 13:46, Jan Beulich wrote:
>> @@ -17,8 +18,22 @@
>>  /* Avoid namespace pollution. */
>>  #undef cmpxchg
>>  #undef cpuid
>> +#undef wbinvd
>>  
>>  #define cpu_has_amd_erratum(nr) \
>>          cpu_has_amd_erratum(&current_cpu_data, AMD_ERRATUM_##nr)
>>  
>> +#define get_stub(stb) ({                                   \
>> +    (stb).addr = this_cpu(stubs.addr) + STUB_BUF_SIZE / 2; \
>> +    ((stb).ptr = map_domain_page(this_cpu(stubs.mfn))) +   \
>> +        ((stb).addr & (PAGE_SIZE - 1));                    \
>> +})
>> +#define put_stub(stb) ({                                   \
>> +    if ( (stb).ptr )                                       \
>> +    {                                                      \
>> +        unmap_domain_page((stb).ptr);                      \
>> +        (stb).ptr = NULL;                                  \
>> +    }                                                      \
>> +})
>> +
> 
> These don't need to be macros, and I suspect a compiler would choose to
> out-of-line get_stub() if it could.

But afaict there's also nothing wrong with them being macros.

>> --- a/xen/arch/x86/x86_emulate/x86_emulate.h
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.h
>> @@ -429,6 +429,18 @@ struct x86_emulate_ctxt
>>      } retire;
>>  };
>>  
>> +struct x86_emulate_stub {
>> +    union {
>> +        void (*func)(void);
>> +        uintptr_t addr;
>> +    };
>> +#ifdef __XEN__
>> +    void *ptr;
>> +#else
>> +    uint8_t buf[32];
> 
> 16 is surely enough? The emulator will #GP if it attempts to fetch more
> than 15 bytes, and only a 'ret' is needed after that.

Maybe, right now. I wanted to leave room for there perhaps being
a case where two instructions could be generated. But of course we
can grow the buffer later. I'll use MAX_INST_LEN + 1 for now.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel