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

[Stefano Stabellini <stefano.stabellini@eu.citrix.com>]

On Wed, 13 Jan 2016, David Vrabel wrote:
> On 12/01/16 12:07, Stefano Stabellini 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.
> 
> This needs much more than just the ability for the L1 dom0 to make
> hypercalls to the L0 hypervisor.
> 
> There's event channels, xenstore, grant tables etc. etc.
> 
> The dom0 kernel would have to gain an additional set of xenbus frontend
> drivers and duplicates of much of drivers/xen/ in Linux that know to
> connect to the L0 instead of L1.

Yes, that's correct.


> Instead, use virtio which will (almost) just work right now.

True, I thought about that too, but one doesn't always get to choose the
set of emulated hardware it gets. On most clouds or virtualization
products, virtio for Xen VMs is not an option, and it doesn't look like
it is going to be an option in the near future either.

That said, even if we add a HVMOP_set_hypercall_dpl hypercall, I agree
that the complexity of duplicating drivers/xen would probably not make
the whole thing worth while, at least in the Linux kernel.