[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.