Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760108AbcLBLof (ORCPT ); Fri, 2 Dec 2016 06:44:35 -0500 Received: from smtp.ctxuk.citrix.com ([185.25.65.24]:17896 "EHLO SMTP.EU.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753678AbcLBLoe (ORCPT ); Fri, 2 Dec 2016 06:44:34 -0500 X-IronPort-AV: E=Sophos;i="5.33,729,1477958400"; d="scan'208";a="36060397" Subject: Re: [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation To: Andy Lutomirski , References: <0a21157c2233ba7d0781bbf07866b3f2d7e7c25d.1480638597.git.luto@kernel.org> CC: One Thousand Gnomes , Borislav Petkov , "linux-kernel@vger.kernel.org" , Brian Gerst , Matthew Whitehead , Henrique de Moraes Holschuh , Peter Zijlstra , Xen-devel List , Boris Ostrovsky , Juergen Gross From: Andrew Cooper Message-ID: Date: Fri, 2 Dec 2016 11:44:30 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: <0a21157c2233ba7d0781bbf07866b3f2d7e7c25d.1480638597.git.luto@kernel.org> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2651 Lines: 88 On 02/12/16 00:35, Andy Lutomirski wrote: > On Xen PV, CPUID is likely to trap, and Xen hypercalls aren't > guaranteed to serialize. (Even CPUID isn't *really* guaranteed to > serialize on Xen PV, but, in practice, any trap it generates will > serialize.) Well, Xen will enabled CPUID Faulting wherever it can, which is realistically all IvyBridge hardware and newer. All hypercalls are a privilege change to cpl0. I'd hope this condition is serialising, but I can't actually find any documentation proving or disproving this. > > On my laptop, CPUID(eax=1, ecx=0) is ~83ns and IRET-to-self is > ~110ns. But Xen PV will trap CPUID if possible, so IRET-to-self > should end up being a nice speedup. > > Cc: Andrew Cooper > Signed-off-by: Andy Lutomirski CC'ing xen-devel and the Xen maintainers in Linux. As this is the only email from this series in my inbox, I will say this here, but it should really be against patch 6. A write to %cr2 is apparently (http://sandpile.org/x86/coherent.htm) not serialising on the 486, but I don't have a manual to hand to check. ~Andrew > --- > arch/x86/xen/enlighten.c | 35 +++++++++++++++++++++++++++++++++++ > 1 file changed, 35 insertions(+) > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > index bdd855685403..1f765b41eee7 100644 > --- a/arch/x86/xen/enlighten.c > +++ b/arch/x86/xen/enlighten.c > @@ -311,6 +311,39 @@ static __read_mostly unsigned int cpuid_leaf1_ecx_set_mask; > static __read_mostly unsigned int cpuid_leaf5_ecx_val; > static __read_mostly unsigned int cpuid_leaf5_edx_val; > > +static void xen_sync_core(void) > +{ > + register void *__sp asm(_ASM_SP); > + > +#ifdef CONFIG_X86_32 > + asm volatile ( > + "pushl %%ss\n\t" > + "pushl %%esp\n\t" > + "addl $4, (%%esp)\n\t" > + "pushfl\n\t" > + "pushl %%cs\n\t" > + "pushl $1f\n\t" > + "iret\n\t" > + "1:" > + : "+r" (__sp) : : "cc"); > +#else > + unsigned long tmp; > + > + asm volatile ( > + "movq %%ss, %0\n\t" > + "pushq %0\n\t" > + "pushq %%rsp\n\t" > + "addq $8, (%%rsp)\n\t" > + "pushfq\n\t" > + "movq %%cs, %0\n\t" > + "pushq %0\n\t" > + "pushq $1f\n\t" > + "iretq\n\t" > + "1:" > + : "=r" (tmp), "+r" (__sp) : : "cc"); > +#endif > +} > + > static void xen_cpuid(unsigned int *ax, unsigned int *bx, > unsigned int *cx, unsigned int *dx) > { > @@ -1289,6 +1322,8 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = { > > .start_context_switch = paravirt_start_context_switch, > .end_context_switch = xen_end_context_switch, > + > + .sync_core = xen_sync_core, > }; > > static void xen_reboot(int reason)