>>> On 12.01.16 at 13:07, <stefano.stabell...@eu.citrix.com> 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). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
