[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 5/9] x86/hypercall: Move the hypercall tables into C
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. > >> +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. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |