xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	StefanoStabellini <stefano.stabellini@citrix.com>,
	IanCampbell <ian.campbell@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH] x86/hvm: Allow the guest to permit the use of userspace hypercalls
Date: Tue, 12 Jan 2016 18:10:03 +0100	[thread overview]
Message-ID: <5695336B.7030205@suse.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1601121702540.13564@kaball.uk.xensource.com>

On 12/01/16 18:05, Stefano Stabellini wrote:
> On Tue, 12 Jan 2016, Jan Beulich wrote:
>>>>> On 12.01.16 at 13:07, <stefano.stabellini@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).
> 
> 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

  reply	other threads:[~2016-01-12 17:10 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-11 13:59 [PATCH] x86/hvm: Allow the guest to permit the use of userspace hypercalls Andrew Cooper
2016-01-11 14:32 ` Paul Durrant
2016-01-11 14:44 ` Jan Beulich
2016-01-11 17:17   ` Andrew Cooper
2016-01-11 18:26     ` David Vrabel
2016-01-11 18:32       ` Andrew Cooper
2016-01-11 18:40         ` David Vrabel
2016-01-11 18:50           ` Andrew Cooper
2016-01-12 12:07       ` Stefano Stabellini
2016-01-12 15:06         ` Jan Beulich
2016-01-12 17:05           ` Stefano Stabellini
2016-01-12 17:10             ` Juergen Gross [this message]
2016-01-12 17:23               ` Stefano Stabellini
2016-01-13  5:12                 ` Juergen Gross
2016-01-13 10:41                   ` Stefano Stabellini
2016-01-13 11:14                     ` Juergen Gross
2016-01-13 11:26                       ` Stefano Stabellini
2016-01-13 11:32                         ` Juergen Gross
2016-01-13 11:42         ` David Vrabel
2016-01-13 12:51           ` Stefano Stabellini
2016-01-12  7:33     ` Jan Beulich
2016-01-12 10:57       ` Andrew Cooper
2016-01-12 11:03         ` George Dunlap
2016-01-14 10:50 ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5695336B.7030205@suse.com \
    --to=jgross@suse.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=david.vrabel@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=stefano.stabellini@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).