From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [semi-urgent Xen CS question] Re: git commit 9fd67b4ed0714ab718f1f9bd14c344af336a6df7 (x86-64: Give vvars their own page) breaks Xen PV guests (64-bit). Date: Wed, 27 Jul 2011 23:07:42 -0700 Message-ID: <4E30FCAE.4070906@goop.org> References: <1093cd3a-acfe-49ab-b410-9fb49b139816@email.android.com> <4E30317E.30706@goop.org> <4E3048B4.6020805@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Andrew Lutomirski Cc: Keir Fraser , xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org On 07/27/2011 09:33 PM, Andrew Lutomirski wrote: > On Sandy Bridge, a null vsyscall takes 373 ns. Without > VCGF_in_syscall, it's 457 ns. The change causes my little test app to > get cs == __USER_CS. Hm, 20% is more noticable than I would hope. What about a regular syscall? > I suspect that Sandy Bridge is just about the worst case. syscall and > sysret are amazingly fast on Sandy Bridge. > Yes, and one presumes it would only get worse. J