Re: [Xen-devel] [PATCH] hvm/altp2m: Clarify the proper way to extend the altp2m interface

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Tue, Jul 10, 2018 at 10:33:22AM +0100, George Dunlap wrote:
> The altp2m functionality was originally envisioned to be used in
> several different configurations, one of which was a single in-guest
> agent that had full operational control of altp2m.  This required the
> single hypercall to be an HVMOP, which is the only type of hypercall
> an HVM guest is allowed to make.

That's not true. HVM guests can use a bunch of hypercalls, like
GNTTABOP, XENMEM, PHYSDEVOP...

> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index e022f5ab0e..90a4be5e86 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4460,6 +4460,34 @@ static int hvmop_get_param(
>      return rc;
>  }
>  
> +/*
> + * altp2m operations are envisioned as being used in several different 
> + * modes:
> + * 
> + * - external: All control and decisions are made by an external agent
> + *   running domain 0.
> + *
> + * - internal: altp2m operations are used exclusively by an in-guest agent
> + *   to protect itself from the guest kernel and in-guest attackers.  
> + * 
> + * - coordinated: An in-guest agent handles #VE and VMFUNCs locally,
> + *   but makes requests of an external entity for bigger changes (such
> + *   as modifying altp2m entires).
> + *
> + * This corresponds to the three values for HVM_PARAM_ALTP2M
> + * (external, mixed, limited). All three models have advantages and
> + * disadvantages.

Shouldn't you use the existing HVM_PARAM_ALTP2M values in the
enumeration above instead of introducing a new nomenclature?

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel