From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH] x86/hvm: Allow the guest to permit the use of userspace hypercalls Date: Wed, 13 Jan 2016 11:42:40 +0000 Message-ID: <56963830.3050201@citrix.com> References: <1452520774-16794-1-git-send-email-andrew.cooper3@citrix.com> <5693CDE302000078000C5788@prv-mh.provo.novell.com> <5693E3BD.6070009@citrix.com> <5693F3B9.5060407@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini , David Vrabel Cc: Andrew Cooper , StefanoStabellini , Ian Campbell , Jan Beulich , Xen-devel List-Id: xen-devel@lists.xenproject.org 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. Instead, use virtio which will (almost) just work right now. David