Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751446AbdGZH1E (ORCPT ); Wed, 26 Jul 2017 03:27:04 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:58749 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751024AbdGZH1C (ORCPT ); Wed, 26 Jul 2017 03:27:02 -0400 Date: Wed, 26 Jul 2017 09:26:54 +0200 From: Heiko Carstens To: Martin Schwidefsky Cc: Guenter Roeck , linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org Subject: Re: Qemu problems in -next with 's390/spinlock: add niai spinlock hints' References: <20170726011451.GA24947@roeck-us.net> <20170726050033.GA3218@osiris> <20170726074044.41bdc796@mschwideX1> <20170726060527.GD3218@osiris> <20170726083100.0146e84a@mschwideX1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170726083100.0146e84a@mschwideX1> User-Agent: Mutt/1.5.24 (2015-08-30) X-TM-AS-GCONF: 00 x-cbid: 17072607-0012-0000-0000-000005665617 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17072607-0013-0000-0000-000018DB6B8A Message-Id: <20170726072654.GE3218@osiris> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-07-26_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707260113 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1434 Lines: 27 > > > Hmm, I though that NIAI is a NOP on older machines. A runtime check for > > > the facility bit is out of the question as the NIAI-7 gets inlined in > > > the spin_unlock code. So yes, the only available fix is to make the > > > NIAI hinting conditional on zEC12. Which is quite ugly as we would need > > > an architecture level set to zEC12 for the distribution kernel to make > > > use of NIAI. > > > > Alternatively you could generate a four-byte nop, and replace that at IPL > > time with the needed NIAI instruction, if the facility is available. Some > > sort of "alternative" code patching infrastructure that x86 already has. > > Not sure if it is worth it, however... > > Patching all spin_unlock inlines? There are a lot of callers for this > function. We could think about an out-of-line spin_unlock and patch this > single function but then we'd loose the advantage of inlining. > I do not think it is worthwhile. > > I pushed an updated patch to the features branch of s390/linux. Should > be in linux-next tomorroy. Thanks. The idea would be to generate an extra section that contains the addresses of the to be patched instructions, and how they need to be patched. That section, plus the code that will do the patching could reside in init data/code sections and would be discarded after. So the additional memory overhead after initialization would be close to zero. However an ifdef is fine as well ;)