|
[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 |