From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PATCH] x86/hvm: Allow the guest to permit the use of userspace hypercalls Date: Tue, 12 Jan 2016 18:10:03 +0100 Message-ID: <5695336B.7030205@suse.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> <5695247D02000078000C5F6D@prv-mh.provo.novell.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 , Jan Beulich Cc: Andrew Cooper , David Vrabel , StefanoStabellini , IanCampbell , Xen-devel List-Id: xen-devel@lists.xenproject.org On 12/01/16 18:05, Stefano Stabellini wrote: > On Tue, 12 Jan 2016, Jan Beulich wrote: >>>>> On 12.01.16 at 13:07, 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? Juergen