Re: [Xen-devel] [PATCH] x86/hvm: Allow the guest to permit the use of userspace hypercalls

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 12 Jan 2016, Juergen Gross wrote:
> On 12/01/16 18:05, Stefano Stabellini wrote:
> > On Tue, 12 Jan 2016, Jan Beulich wrote:
> >>>>> On 12.01.16 at 13:07, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> >>> On Mon, 11 Jan 2016, David Vrabel wrote:
> >>>> On 11/01/16 17:17, Andrew Cooper wrote:
> >>>>> So from one point of view, sufficient justification for this change is
> >>>>> "because the Linux way isn't the only valid way to do this".
> >>>>
> >>>> "Because we can" isn't a good justification for adding something new.
> >>>> Particularly something that is trivially easy to (accidentally) misuse
> >>>> and open a big security hole between userspace and kernel.
> >>>>
> >>>> The vague idea for a userspace netfront that's floating around
> >>>> internally is also not a good reason for pushing this feature at this 
> >>>> time.
> >>>
> >>> I agree with David, but I might have another good use case for this.
> >>>
> >>> Consider the following scenario: we have a Xen HVM guest, with Xen
> >>> installed inside of it (nested virtualization). I'll refer to Xen
> >>> running on the host as L0 Xen and Xen running inside the VM as L1 Xen.
> >>> Similarly we have two dom0 running, the one with access to the physical
> >>> hardware, L0 Dom0, and the one running inside the VM, L1 Dom0.
> >>>
> >>> Let's suppose that we want to lay the groundwork for L1 Dom0 to use PV
> >>> frontend drivers, netfront and blkfront to speed up execution. In order
> >>> to do that, the first thing it needs to do is making an hypercall to L0
> >>> Xen. That's because netfront and blkfront needs to communicate with
> >>> netback and blkback in L0 Dom0: event channels and grant tables are the
> >>> ones provided by L0 Xen.
> >>
> >> That's again a layering violation (bypassing the L1 hypervisor).
> > 
> > True, but in this scenario it might be necessary for performance
> > reasons: otherwise every hypercall would need to bounce off L1 Xen,
> > possibly cancelling the benefits of running netfront and blkfront in the
> > first place. I don't have numbers though.
> 
> How is this supposed to work? How can dom0 make hypercalls to L1 _or_ L0
> hypervisor? How can it select the hypervisor it is talking to?

From L0 Xen point of view, the guest is just a normal PV on HVM guest,
it doesn't matter what's inside, so L1 Dom0 is going to make hypercalls
to L0 Xen like any other PV on HVM guests: mapping the hypercall page by
writing to the right MSR, retrieved via cpuid, then calling into the
hypercall page. L0 Xen would populate the hypercall page as usual for PV
on HVM guests, using vmcall instructions. However once that is done, L0
Xen would still refuse the hypercalls because they are issued from ring
3.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel