Re: [Xen-devel] [PATCH 5/9] x86/hypercall: Move the hypercall tables into C

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 02.08.16 at 15:30, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 02/08/16 14:23, Jan Beulich wrote:
>>>>> On 18.07.16 at 11:51, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> +hypercall_fn_t *const hypercall_table[NR_hypercalls] = {
>>> +    HYPERCALL(set_trap_table),
>>> +    HYPERCALL(mmu_update),
>>> +    HYPERCALL(set_gdt),
>>> +    HYPERCALL(stack_switch),
>>> +    HYPERCALL(set_callbacks),
>>> +    HYPERCALL(fpu_taskswitch),
>>> +    HYPERCALL(sched_op_compat),
>>> +    HYPERCALL(platform_op),
>>> +    HYPERCALL(set_debugreg),
>>> +    HYPERCALL(get_debugreg),
>>> +    HYPERCALL(update_descriptor),
>>> +    HYPERCALL(memory_op),
>>> +    HYPERCALL(multicall),
>>> +    HYPERCALL(update_va_mapping),
>>> +    HYPERCALL(set_timer_op),
>>> +    HYPERCALL(event_channel_op_compat),
>>> +    HYPERCALL(xen_version),
>>> +    HYPERCALL(console_io),
>>> +    HYPERCALL(physdev_op_compat),
>>> +    HYPERCALL(grant_table_op),
>>> +    HYPERCALL(vm_assist),
>>> +    HYPERCALL(update_va_mapping_otherdomain),
>>> +    HYPERCALL(iret),
>>> +    HYPERCALL(vcpu_op),
>>> +    HYPERCALL(set_segment_base),
>>> +    HYPERCALL(mmuext_op),
>>> +    HYPERCALL(xsm_op),
>>> +    HYPERCALL(nmi_op),
>>> +    HYPERCALL(sched_op),
>>> +    HYPERCALL(callback_op),
>>> +#ifdef CONFIG_XENOPROF
>>> +    HYPERCALL(xenoprof_op),
>>> +#endif
>>> +    HYPERCALL(event_channel_op),
>>> +    HYPERCALL(physdev_op),
>>> +    HYPERCALL(hvm_op),
>>> +    HYPERCALL(sysctl),
>>> +    HYPERCALL(domctl),
>>> +#ifdef CONFIG_KEXEC
>>> +    HYPERCALL(kexec_op),
>>> +#endif
>>> +#ifdef CONFIG_TMEM
>>> +    HYPERCALL(tmem_op),
>>> +#endif
>> To be honest I'd prefer the necessary #ifdef-ery to live in hypercall.h,
>> the more that then ARM could (if they want) benefit from that too.
> 
> Which #ifdefary?
> 
> HYPERCALL() can't be used by ARM.

I mean just the #ifdef-s above, not the HYPERCALL() lines. Clearly
you can do

#ifndef CONFIG_TMEM
# define do_tmem_op NULL
#endif

and alike in the header?

>>> +hypercall_fn_t *const compat_hypercall_table[NR_hypercalls] = {
>> Is it really helpful to create two separate tables here, just to then
>> merge them in patch 7?
> 
> This is necessary, so the untangling of multicalls can happen in patch 6.
> 
> The only other bisectable option is to merge patches 5-7, which is
> definitely too complicated to review.

Okay, I guess I'll have to look at 6 before being able to judge.

Jan


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