Re: [Xen-devel] RFC Userspace hypercalls

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.01.16 at 15:44, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 06/01/16 14:14, Jan Beulich wrote:
>>>>> On 06.01.16 at 12:44, <andrew.cooper3@xxxxxxxxxx> 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.

That's not the part I meant it could have been intended to match
in behavior; I only referred to the privilege aspect.

>>> 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.

Task switch? On the hypercall path?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel