Re: [Xen-devel] RFC Userspace hypercalls

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 07/01/16 10:42, Ian Campbell wrote:
> On Wed, 2016-01-06 at 11:44 +0000, Andrew Cooper wrote:
>> 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).
> All three simultaneously, or it picks one depending on the scenario?

Currently all three (for simplicity), but I want to make the precise
setup configurable.

>
>> 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.
> And in these test cases there is useful logging to be done between the
> break the world and repair the world phases which I suppose follows if
> things didn't crash?

Precisely.

>
>> 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?
> Would a xenconsoled mode which polls for updates (on specific guests only),
> along with the guest spinning waiting for the cons pointer to catch the
> prod one if it cares about synchronous logging be sufficient for this use
> case?

The framework already waits for cons to catch prod.

>
> Other random ideas:
> Implement the debug io port for PV guests too
> Log to a in guest buffer, as David suggested, possibly use xenaccess or
> similar to trap updates or as a doorbell.

Specifically not.  I have been bitten by that one too many times already.

In the case of XSA regression tests, or indeed the random x86
instruction executor which discovered XSA-44, the logging needs to have
escaped the host before the action is taken, or it all gets lost in a
host crash.

This is why console_io hypercalls are also used.

~Andrew

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