Re: [PATCH v3 3/4] x86/pvh: Handle hypercalls for 32b PVH guests

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 07/23/2015 10:21 AM, Jan Beulich wrote:
>>>> On 11.07.15 at 00:20, <boris.ostrovsky@oracle.com> wrote:
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> ---
>> Changes in v3:
>> * Defined compat_mmuext_op(). (XEN_GUEST_HANDLE_PARAM(mmuext_op_compat_t)
>>    is not defined in header files so I used 'void' type.
> How is it not? It's in compat/xen.h (which is a generated header).

compat/xen.h has DEFINE_COMPAT_HANDLE(mmuext_op_compat_t) (which is 
__compat_handle_mmuext_op_compat_t).

We need XEN_GUEST_HANDLE(mmuext_op_compat_t), which is 
__guest_handle_mmuext_op_compat_t. And I wasn't sure it's worth 
explicitly adding it to a header file (like I think what we do for 
vcpu_runstate_info_compat_t in sched.h);


>
>> @@ -4951,6 +4950,29 @@ static hvm_hypercall_t *const pvh_hypercall64_table[NR_hypercalls] = {
>>       [ __HYPERVISOR_arch_1 ] = (hvm_hypercall_t *)paging_domctl_continuation
>>   };
>>   
>> +extern int compat_mmuext_op(XEN_GUEST_HANDLE_PARAM(void) cmp_uops,
>> +                            unsigned int count,
>> +                            XEN_GUEST_HANDLE_PARAM(uint) pdone,
>> +                            unsigned int foreigndom);
>> +static hvm_hypercall_t *const pvh_hypercall32_table[NR_hypercalls] = {
>> +    HYPERCALL(platform_op),
>> +    COMPAT_CALL(memory_op),
>> +    HYPERCALL(xen_version),
>> +    HYPERCALL(console_io),
>> +    [ __HYPERVISOR_grant_table_op ]  =
>> +        (hvm_hypercall_t *)hvm_grant_table_op_compat32,
>> +    COMPAT_CALL(vcpu_op),
>> +    COMPAT_CALL(mmuext_op),
>> +    HYPERCALL(xsm_op),
>> +    COMPAT_CALL(sched_op),
>> +    HYPERCALL(event_channel_op),
>> +    [ __HYPERVISOR_physdev_op ] = (hvm_hypercall_t *)hvm_physdev_op_compat32,
>> +    HYPERCALL(hvm_op),
>> +    HYPERCALL(sysctl),
>> +    HYPERCALL(domctl),
>> +    [ __HYPERVISOR_arch_1 ] = (hvm_hypercall_t *)paging_domctl_continuation
> Looks like you didn't fully sync with staging - did you forget that it
> was you who added xenpmu_op to the 64-bit counterpart?

I think I posted this before VPMU got committed. But yes...

> Without that ...
>
>> @@ -4981,7 +5003,7 @@ int hvm_do_hypercall(struct cpu_user_regs *regs)
>>           return viridian_hypercall(regs);
>>   
>>       if ( (eax >= NR_hypercalls) ||
>> -         (is_pvh_domain(currd) ? !pvh_hypercall64_table[eax]
>> +         (is_pvh_domain(currd) ? !pvh_hypercall32_table[eax]
>>                                  : !hvm_hypercall32_table[eax]) )
> ... this will break (as we're assuming 32- and 64-bit tables to be fully
> in sync here; there's still the pending work item of constructing these
> tables so that this has a better chance of not getting broken).

So you prefer to have full check --- explicitly for both 32- and 64-bit, 
right?

-boris