Re: RFC Userspace hypercalls

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 06/01/16 14:14, Jan Beulich wrote:
>>>> On 06.01.16 at 12:44, <andrew.cooper3@citrix.com> wrote:
>> The HVM ABI (for whatever reason) unilaterally fails
>> a userspace hypercall with -EPERM, making it impossible for the kernel
>> to trap-and-forward even it wanted to.
> Perhaps just to match PV behavior?

But it doesn't.  PV userspace hypercalls currently end up in the guest
kernel at the sysenter or int $0x82 handler.

>
>> There are already scenarios under test where we cannot rely on the test
>> kernel having a fully functioning set of entry points (e.g. the DPL part
>> of the test above).  Therefore I specifically want to make it possible
>> to make userspace hypercalls, rather than simply making them possible to
>> be trapped-and-forwarded.
>>
>>
>> As a result, I proposing introducing a hypercall which allows a domain
>> to adjust its entry criteria for hypercalls (e.g. set_hypercall_iopl). 
>> Doing this for HVM guests is straight forward, but PV guests are harder,
>> as they bounce through Xen entrypoints.
> The primary question I have is whether this proposal is going to be
> of use to anything other than your test framework (i.e. namely any
> "ordinary" guests).

We did have an internal request for an HVM guest userspace netfront
driver to be able to use evntchnop calls directly.

The use of userspace hypercalls is restricted to single appliances
(rather than general purpose VMs), but isn't limited to my test
framework specifically.

> A second question then would be whether the PV case really needs to be handled.

Yes - I am going out of my way to make the test environments as
inequivalent as possible.

>
>> For PV guests, I propose that userspace hypercalls get implemented with
>> the int $0x82 path exclusively.  i.e. enabling userspace hypercalls
>> causes the hypercall page writing logic to consider the guest a ring1
>> kernel, and the int $0x82 entrypoint suitably delegates between a
>> regular hypercall and a compat hypercall.
> With int $0x82 being the primary hypercall path for 32-bit guests,
> I'd be concerned of any code addition, especially that of further
> conditionals.

The overhead of one extra conditional in the hypercall path is lost in
the noise, compared to the overhead of the task switch itself.

~Andrew