RFC Userspace hypercalls

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

Hi,

I am in the middle of getting my Xen Test Framework working and usable.

Embarrassingly, the unit test I hacked up for investigating XSA-106
(which was the inspiration to make the framework) correctly identifies
the regression caused by XSA-156.  To avoid similar situations in the
future, I am getting the XTF usable as a matter of priority.

The XTF uses a flat, shared address space, with the test free to change
cpl at part of normal operation.  For the XSA-106 usecase, this was to
confirm that the x86 emulator correctly performed dpl checks on emulated
exception injection.

All console logging is synchronous (to ensure that log messages have
escaped the VM before an action occurs) and by default, an HVM test will
use the qemu debug port, console_io hypercall, and PV console (which
uses evtchn hypercalls).

This causes problems when the test moves into userspace.  The qemu debug
port can trivially be fixed by setting IOPL=3, but the hypercalls are
more problematic.  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.

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.

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.

Thoughts?

~Andrew