Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752420AbcLBR0a (ORCPT ); Fri, 2 Dec 2016 12:26:30 -0500 Received: from smtp.ctxuk.citrix.com ([185.25.65.24]:13777 "EHLO SMTP.EU.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751347AbcLBR03 (ORCPT ); Fri, 2 Dec 2016 12:26:29 -0500 X-IronPort-AV: E=Sophos;i="5.33,287,1477958400"; d="scan'208";a="36083018" 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: Linus Torvalds , Boris Ostrovsky , Xen-devel List , Juergen Gross , Borislav Petkov , Matthew Whitehead , One Thousand Gnomes , Henrique de Moraes Holschuh , Brian Gerst , "linux-kernel@vger.kernel.org" , X86 ML , Peter Zijlstra From: Andrew Cooper Message-ID: <168ef9ef-a2dc-1c7f-2462-b1ce0cc40c71@citrix.com> Date: Fri, 2 Dec 2016 17:26:26 +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: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) 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: 3200 Lines: 67 On 02/12/16 17:23, Andy Lutomirski wrote: > On Fri, Dec 2, 2016 at 9:16 AM, Andrew Cooper wrote: >> On 02/12/16 17:07, Andy Lutomirski wrote: >>> On Dec 2, 2016 3:44 AM, "Andrew Cooper" wrote: >>>> 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. >>> I don't know for sure. IRET is serializing, and if Xen returns using >>> IRET, we're fine. >> All returns to a 64bit PV guest at defined points (hypercall return, >> exception entry, etc) are from SYSRET, not IRET. > But CPUID faulting isn't like this, right? Unless Xen does > opportunistic SYSRET. Correct. Xen doesn't do opportunistic SYSRET. > >> Talking of, I still have a patch to remove >> PARAVIRT_ADJUST_EXCEPTION_FRAME which I need to complete and send upstream. >> >>>>> 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. >>> I'll quote the (modern) SDM. For self-modifying code "The use of one >>> of these options is not required for programs intended to run on the >>> Pentium or Intel486 processors, >>> but are recommended to ensure compatibility with the P6 and more >>> recent processor families.". For cross-modifying code "The use of >>> this option is not required for programs intended to run on the >>> Intel486 processor, but is recommended >>> to ensure compatibility with the Pentium 4, Intel Xeon, P6 family, and >>> Pentium processors." So I'm not sure there's a problem. >> Fair enough. (Assuming similar properties hold for the older processors >> of other vendors.) > No, you were right -- a different section of the SDM contradicts it: > > For Intel486 processors, a write to an instruction in the cache will > modify it in both the cache and memory, but if > the instruction was prefetched before the write, the old version of > the instruction could be the one executed. To > prevent the old instruction from being executed, flush the instruction > prefetch unit by coding a jump instruction > immediately after any write that modifies an instruction. :( Presumably this means patching has been subtly broken forever on the 486? ~Andrew