Currently, hypercalls issued from HVM userspace will unconditionally fail with
-EPERM.
This is inflexible, and a guest may wish to allow userspace to make
hypercalls.
Introduce HVMOP_set_hypercall_dpl which allows the guest to alter the
permissions check for hypercalls. It behaves exactly like t
PATCH] x86/hvm: Allow the guest to permit the use of
> userspace hypercalls
>
> Currently, hypercalls issued from HVM userspace will unconditionally fail with
> -EPERM.
>
> This is inflexible, and a guest may wish to allow userspace to make
> hypercalls.
>
> Introduce H
>>> On 11.01.16 at 14:59, wrote:
> Currently, hypercalls issued from HVM userspace will unconditionally fail
> with -EPERM.
>
> This is inflexible, and a guest may wish to allow userspace to make
> hypercalls.
I thought previous discussion had made clear that routing these
through ioctls or alik
On 11/01/16 14:44, Jan Beulich wrote:
On 11.01.16 at 14:59, wrote:
>> Currently, hypercalls issued from HVM userspace will unconditionally fail
>> with -EPERM.
>>
>> This is inflexible, and a guest may wish to allow userspace to make
>> hypercalls.
> I thought previous discussion had made cle
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 (ac
On 11/01/16 18:26, 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.
"Becaus
On 11/01/16 18:32, Andrew Cooper wrote:
> On 11/01/16 18:26, 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 ju
On 11/01/16 18:40, David Vrabel wrote:
> On 11/01/16 18:32, Andrew Cooper wrote:
>> On 11/01/16 18:26, 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
>>> On 11.01.16 at 18:17, wrote:
> On 11/01/16 14:44, Jan Beulich wrote:
> On 11.01.16 at 14:59, wrote:
>>> Currently, hypercalls issued from HVM userspace will unconditionally fail
>>> with -EPERM.
>>>
>>> This is inflexible, and a guest may wish to allow userspace to make
>>> hypercalls.
>>
On 12/01/16 07:33, Jan Beulich wrote:
On 11.01.16 at 18:17, wrote:
>> On 11/01/16 14:44, Jan Beulich wrote:
>> On 11.01.16 at 14:59, wrote:
Currently, hypercalls issued from HVM userspace will unconditionally fail
with -EPERM.
This is inflexible, and a guest may wish
On Tue, Jan 12, 2016 at 10:57 AM, Andrew Cooper
wrote:
> Writing a PV guest from scratch has been very enlightening to
> demonstrate how much of a trainwreck the ABI is. Almost nothing is
> documented. Some bits which are documented are misleading. Several
> areas needlessly deviate from x86 ar
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.
>
>>> 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
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
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
> "be
On Tue, 12 Jan 2016, Juergen Gross wrote:
> 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,
On 12/01/16 18:23, Stefano Stabellini wrote:
> On Tue, 12 Jan 2016, Juergen Gross wrote:
>> 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
On Wed, 13 Jan 2016, Juergen Gross wrote:
> On 12/01/16 18:23, Stefano Stabellini wrote:
> > On Tue, 12 Jan 2016, Juergen Gross wrote:
> >> 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,
On 13/01/16 11:41, Stefano Stabellini wrote:
> On Wed, 13 Jan 2016, Juergen Gross wrote:
>> On 12/01/16 18:23, Stefano Stabellini wrote:
>>> On Tue, 12 Jan 2016, Juergen Gross wrote:
On 12/01/16 18:05, Stefano Stabellini wrote:
> On Tue, 12 Jan 2016, Jan Beulich wrote:
> On 12.01.1
On Wed, 13 Jan 2016, Juergen Gross wrote:
> On 13/01/16 11:41, Stefano Stabellini wrote:
> > On Wed, 13 Jan 2016, Juergen Gross wrote:
> >> On 12/01/16 18:23, Stefano Stabellini wrote:
> >>> On Tue, 12 Jan 2016, Juergen Gross wrote:
> On 12/01/16 18:05, Stefano Stabellini wrote:
> > On Tue
On 13/01/16 12:26, Stefano Stabellini wrote:
> On Wed, 13 Jan 2016, Juergen Gross wrote:
>> On 13/01/16 11:41, Stefano Stabellini wrote:
>>> On Wed, 13 Jan 2016, Juergen Gross wrote:
On 12/01/16 18:23, Stefano Stabellini wrote:
> On Tue, 12 Jan 2016, Juergen Gross wrote:
>> On 12/01/16
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
On Wed, 13 Jan 2016, David Vrabel wrote:
> 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
On Mon, 2016-01-11 at 13:59 +, Andrew Cooper wrote:
> Arm folks: Is something like this sufficiently generic to be useful on
> Arm, perhaps with more generic naming?
ARM's HVC instruction is always invalid from userspace, i.e. it would
result in #UNDEF and there is no control bit to make it do
24 matches
Mail list logo