Messages in this thread | | | Subject | Re: [Xen-devel] [RFC PATCH 04/16] x86/xen: hypercall support for xenhost_t | From | Andrew Cooper <> | Date | Fri, 14 Jun 2019 09:00:41 +0100 |
| |
On 14/06/2019 08:35, Juergen Gross wrote: > 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@oracle.com> >>> >>> 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.
That is exactly the point I was trying to make.
If L2 is an HVM guest, then both its hypercall pages will be using VMCALL/VMMCALL which will end up making hypercalls to L1, rather than having one go to L0.
If L2 is a PV guest, then one hypercall page will be SYSCALL/INT 82 which will go to L1, and one will be VMCALL/VMMCALL which goes to L0, but L0 will see it from ring1/ring3 and reject the hypercall.
However you nest the system, every guest only has a single occurrence of "supervisor software", so only has a single context that will be tolerated to make hypercalls by the next hypervisor up.
~Andrew
| |