From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: RFC Userspace hypercalls Date: Thu, 7 Jan 2016 10:55:56 +0000 Message-ID: <568E443C.1010300@citrix.com> References: <568CFE3A.8080505@citrix.com> <1452163347.21055.178.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1452163347.21055.178.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Xen-devel List Cc: Keir Fraser , Tim Deegan , Jan Beulich List-Id: xen-devel@lists.xenproject.org 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