Re: [Xen-devel] [RFC PATCH 04/16] x86/xen: hypercall support for xenhost_t
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 >>> >>> 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
Re: [Xen-devel] [RFC PATCH 04/16] x86/xen: hypercall support for xenhost_t
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 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
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 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-de...@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 04/16] x86/xen: hypercall support for xenhost_t
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 Again, what is the hypervisor nesting and/or guest layout here? 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. ~Andrew
