Re: [Xen-devel] [PATCH] xen/x86: Improve hypercall page writing

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.12.16 at 13:21, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 20/12/2016 07:48, Jan Beulich wrote:
>>
>>> @@ -398,10 +400,11 @@ static void 
>>> hypercall_page_initialise_ring1_kernel(void 
> *hypercall_page)
>>>       * calling it.
>>>       */
>>>      p = (char *)(hypercall_page + (__HYPERVISOR_iret * 32));
>>> -    *(u8  *)(p+ 0) = 0x50;    /* push %eax */
>>> -    *(u8  *)(p+ 1) = 0xb8;    /* mov  $__HYPERVISOR_iret,%eax */
>>> -    *(u32 *)(p+ 2) = __HYPERVISOR_iret;
>>> -    *(u16 *)(p+ 6) = (HYPERCALL_VECTOR << 8) | 0xcd; /* int  $xx */
>>> +    memcpy(p,
>>> +           "\x50"                 /* push %eax */
>>> +           "\xb8\x17\x00\x00\x00" /* mov  $__HYPERVISOR_iret, %eax */
>>> +           "\xcd\x82",            /* int  $HYPERCALL_VECTOR */
>> here as a good idea.
> 
> Well, they are fixed in the ABI.  It is not as if we could ever change them.
> 
>>  If you used a static const uint8_t[] instead of
>> a string literal (which even includes a pointless nul terminator), all of
>> this could be avoided afaict.
> 
> I can see how that would work for the `int $0x82` case, but how do you
> propose fitting 4 bytes of __HYPERVISOR_iret into an initialiser for a
> uint8_t array?

One byte __HYPERVISOR_iret, the other three zeros. perhaps
accompanied by a BUILD_BUG_ON(). Another alternative would
be a static const struct.

Jan


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