Re: [Xen-devel] RFC Userspace hypercalls

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

> 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). A second question then would be whether the PV
case really needs to be handled.

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

Jan


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