From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: RFC Userspace hypercalls Date: Wed, 6 Jan 2016 16:20:12 +0000 Message-ID: <568D3EBC.5090701@citrix.com> References: <568CFE3A.8080505@citrix.com> <568D2F4002000078000C3F7E@prv-mh.provo.novell.com> <568D2860.3010807@citrix.com> <568D4A3402000078000C411F@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <568D4A3402000078000C411F@prv-mh.provo.novell.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: Jan Beulich Cc: Keir Fraser , Tim Deegan , Xen-devel List List-Id: xen-devel@lists.xenproject.org On 06/01/16 16:09, Jan Beulich wrote: > >>>> 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. >> The overhead of one extra conditional in the hypercall path is lost in >> the noise, compared to the overhead of the task switch itself. > Task switch? On the hypercall path? Apologies - I meant the context switch caused by `int $0x82`. ~Andrew