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

From: George Dunlap <george.dunlap@citrix.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>, Tim Deegan <tim@xen.org>,
	Julien Grall <julien.grall@arm.com>,
	Jan Beulich <jbeulich@suse.com>,
	Tamas K Lengyel <tamas.lengyel@zentific.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH] hvm/altp2m: Clarify the proper way to extend the altp2m interface
Date: Tue, 10 Jul 2018 11:09:36 +0100	[thread overview]
Message-ID: <d5481c8c-2ac7-b6d5-f5be-4967fd02c5cc@citrix.com> (raw)
In-Reply-To: <20180710094309.ny46hu6g4cl63cpv@mac.bytemobile.com>

On 07/10/2018 10:43 AM, Roger Pau Monné wrote:
> 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...

But it can't maken DOMCTLs, which would be the other natural fit.  I'll
see if I can capture that accurately.

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

I did think about that.  The problem is that 'mixed' is basically the
wrong label.  Or rather, it covers two different use cases: A more fully
empowered guest agent coordinating with an external agent, and a solo
guest agent doing everything itself.

Replacing 'coordinated' with 'limited' might make sense though.

 -George

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