[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] RFC Userspace hypercalls
>>> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |