[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC PATCH 04/16] x86/xen: hypercall support for xenhost_t



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?

Ankur


~Andrew

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



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.