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, 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.

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