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 [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
