Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752421AbdCEUNP (ORCPT ); Sun, 5 Mar 2017 15:13:15 -0500 Received: from mx2.suse.de ([195.135.220.15]:52415 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752213AbdCEUNO (ORCPT ); Sun, 5 Mar 2017 15:13:14 -0500 Date: Sun, 5 Mar 2017 20:54:33 +0100 From: Borislav Petkov To: Linus Torvalds , Logan Gunthorpe Cc: Peter Anvin , Thomas Gleixner , Ingo Molnar , Tony Luck , Al Viro , the arch/x86 maintainers , Linux Kernel Mailing List Subject: Re: Question Regarding ERMS memcpy Message-ID: <20170305195432.6occvwaujq3l4ejl@pd.tnic> References: <20170304224341.zfp4fl37ypt57amg@pd.tnic> <5CCEF10D-5647-4503-A398-0681DF2C8847@zytor.com> <20170305001447.kcxignj3nsq35vci@pd.tnic> <20170305003349.6kgq4ovj7ipezfxu@pd.tnic> <20170305095059.l4od2yjqm5yxx6ln@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2151 Lines: 64 On Sun, Mar 05, 2017 at 11:19:42AM -0800, Linus Torvalds wrote: > Actually, the "fromio/toio" code should never use regular memcpy(). > There used to be devices that literally broke on 64-bit accesses due > to broken PCI crud. > > We seem to have broken this *really* long ago, though. I wonder why nothing blew up or failed strangely by now... > On x86-64 we used to have a special __inline_memcpy() that copies our > historical It is still there in arch/x86/include/asm/string_64.h. The comment "Only used for special circumstances." over it is grossly understating it. > 32-bit thing, and was used for memcpy_fromio() and memcpy_toio(). That > was then undone by commit 6175ddf06b61 ("x86: Clean up mem*io > functions") > > That commit says > > "Iomem has no special significance on x86" > > but that's not strictly true. iomem is in the same address space and > uses the same access instructions as regular memory, but iomem _is_ > special. > > And I think it's a bug that we use "memcpy()" on it. Not because of > any gcc issues, but simply because our own memcpy() optimizations are > not appropriate for iomem. > > For example, "rep movsb" really is the right thing to use on normal > memory on modern CPU's. So Logan's box is a SNB and it doesn't have the ERMS optimizations. Are you saying, regardless, we should let gcc put REP; MOVSB for smaller sizes? Because gcc does generate a REP; MOVSB there when it puts its own memcpy, see mail upthread. (Even though that is wrong to do on iomem.) > But it is *not* the right thing to use on IO memory, because the CPU > only does the magic cacheline access optimizations on cacheable > memory! Ah, yes. > So I think we should re-introduce that old "__inline_memcpy()" as that > special "safe memcpy" thing. Not just for KMEMCHECK, and not just for > 64-bit. Logan, wanna give that a try, see if it takes care of your issue? Oh, and along with the revert we would need a big fat warning explaining why we need that special memcpy for IO memory. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --