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