>>> On 18.07.16 at 11:51, <andrew.coop...@citrix.com> 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.

> +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?

> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -682,68 +682,6 @@ ENTRY(exception_table)
>          .endr
>          .size exception_table, . - exception_table
>  
> -#ifndef CONFIG_KEXEC
>[...]
> -        .endr
>  
>  /* Table of automatically generated entry points.  One per vector. */

Please don't leave behind two blank lines.

Jan


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

Reply via email to