Re: [Xen-devel] [RFC PATCH 04/16] x86/xen: hypercall support for xenhost_t
From: Juergen Gross
Date: Fri Jun 14 2019 - 03:40:11 EST
On 14.06.19 09:20, Ankur Arora wrote:
On 2019-06-12 2:15 p.m., Andrew Cooper wrote:
On 09/05/2019 18:25, Ankur Arora wrote:
Allow for different hypercall implementations for different xenhost
types.
Nested xenhost, which has two underlying xenhosts, can use both
simultaneously.
The hypercall macros (HYPERVISOR_*) implicitly use the default xenhost.x
A new macro (hypervisor_*) takes xenhost_t * as a parameter and does the
right thing.
TODO:
ÂÂ - Multicalls for now assume the default xenhost
ÂÂ - xen_hypercall_* symbols are only generated for the default xenhost.
Signed-off-by: Ankur Arora <ankur.a.arora@xxxxxxxxxx>
Again, what is the hypervisor nesting and/or guest layout here?
Two hypervisors, L0 and L1, and the guest is a child of the L1
hypervisor but could have PV devices attached to both L0 and L1
hypervisors.
I can't think of any case where a single piece of software can
legitimately have two hypercall pages, because if it has one working
one, it is by definition a guest, and therefore not privileged enough to
use the outer one.
Depending on which hypercall page is used, the hypercall would
(eventually) land in the corresponding hypervisor.
Juergen elsewhere pointed out proxying hypercalls is a better approach,
so I'm not really considering this any more but, given this layout, and
assuming that the hypercall pages could be encoded differently would it
still not work?
Hypercalls might work, but it is a bad idea and a violation of layering
to let a L1 guest issue hypercalls to L0 hypervisor, as those hypercalls
could influence other L1 guests and even the L1 hypervisor.
Hmm, thinking more about it, I even doubt those hypercalls could work in
all cases: when issued from a L1 PV guest the hypercalls would seem to
be issued from user mode for the L0 hypervisor, and this is not allowed.
Juergen