[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2] x86/hvm: unify HVM and PVH hypercall tables.
>>> On 15.05.14 at 12:53, <tim@xxxxxxx> wrote: > Stage one of many in merging PVH and HVM code in the hypervisor. > > This exposes a few new hypercalls to HVM guests, all of which were > already available to PVH ones: > > - XENMEM_memory_map / XENMEM_machine_memory_map / XENMEM_machphys_mapping: > These are basically harmless, if a bit useless to plain HVM. > > - VCPUOP_send_nmi / VCPUOP_initialise / VCPUOP[_is]_up / VCPUOP_down > This will eventually let HVM guests bring up APs the way PVH ones do. > For now, the VCPUOP_initialise paths are still gated on is_pvh. > - VCPUOP_get_physid > Harmless. > > - __HYPERVISOR_platform_op (XSM_PRIV callers only). > > - __HYPERVISOR_mmuext_op. > The pagetable manipulation MMUEXT ops are already denied > (or no-ops) to paging_mode_refcounts() domains; the baseptr ones > are already denied to paging_mode_translate() domains. > I have restricted MMUEXT[UN]MARK_SUPER to !paging_mode_refcounts() > domains as well, as I can see no need for them in PVH. > I have also restricted MMUEXT_CLEAR_PAGE / MMUEXT_COPY_PAGE > to PV domains only, as there is no need for them in HVM/PVH ones > and they would lead to complication with sharing/paging operations. > That leaves TLB and cache flush operations, which are OK. > > - PHYSDEVOP_* (only for hardware control domains). > Also make ops that touch PV vcpu state (PHYSDEVOP_set_iopl and > PHYSDEVOP_set_iobitmap) gate on is_pv rather than !is_pvh. > > PVH guests can also see a few hypercalls that they couldn't before, > but which were already available to HVM guests: > > - __HYPERVISOR_set_timer_op > > - __HYPERVISOR_tmem_op > > Signed-off-by: Tim Deegan <tim@xxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> pending clarification on whether ... > @@ -4002,11 +3938,13 @@ static hvm_hypercall_t *const > hvm_hypercall64_table[NR_hypercalls] = { > static hvm_hypercall_t *const hvm_hypercall32_table[NR_hypercalls] = { > [ __HYPERVISOR_memory_op ] = (hvm_hypercall_t *)hvm_memory_op_compat32, > [ __HYPERVISOR_grant_table_op ] = (hvm_hypercall_t > *)hvm_grant_table_op_compat32, > - [ __HYPERVISOR_vcpu_op ] = (hvm_hypercall_t *)hvm_vcpu_op_compat32, > [ __HYPERVISOR_physdev_op ] = (hvm_hypercall_t *)hvm_physdev_op_compat32, > + HYPERCALL(platform_op), ... this wouldn't also need to use COMPAT_CALL(). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |