From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: =?utf-8?q?=3CBATV+582a5e42c11197663328+5363+infradead=2Eorg+d?= =?utf-8?q?wmw2=40twosheds=2Esrs=2Einfradead=2Eorg=3E?= Received: from twosheds.infradead.org ([2001:8b0:10b:1:21d:7dff:fe04:dbe2]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from =?utf-8?q?=3CBATV+582a5e42c11197663328+5363+infradea?= =?utf-8?q?d=2Eorg+dwmw2=40twosheds=2Esrs=2Einfradead=2Eorg=3E=29?= id 1fD2wK-0000jh-PM for speck@linutronix.de; Mon, 30 Apr 2018 09:09:38 +0200 Received: from [2001:8b0:10b:1::b8f] by twosheds.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1fD2wI-0007jo-8Y for speck@linutronix.de; Mon, 30 Apr 2018 07:09:34 +0000 Message-ID: <1525072169.9367.10.camel@infradead.org> Subject: [MODERATED] Re: [patch V7 03/15] SBB 3 From: David Woodhouse In-Reply-To: References: <20180429193045.711908246@linutronix.de> <20180429193937.704474597@linutronix.de> Date: Mon, 30 Apr 2018 08:09:29 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: speck@linutronix.de List-ID: On Sun, 2018-04-29 at 16:31 -0700, speck for Linus Torvalds wrote: > > But more importantly, why do we have those odd "mov" instructions at all? > > Why does this code not just do > >     { unsigned int ax, dx, cx; >       asm volatile(ALTERNATIVE("","wrmsr",_feature) >         :"=a" (ax), "=c" (cx), "=d" (dx) >         :"0" (_val), "1" (_msr) >         :"memory"); >     } > > which seems simpler and better for gcc to set up? Sure, it makes the  > setup be unconditional, but it effectively already was (because of that  > memory setup). > > But I guess it doesn't much _matter_. FWIW we have those mov instructions because there was much bikeshedding of this the first time round, and people really wanted the ax/cx/dx setup not to happen in the ALTERNATIVE case. It *wasn't* unconditional when it was all immediates, and I was losing the will to live. As you say, it doesn't much matter. We could still make it all go away in the ALTERNATIVE case by passing in *only* the immediate value to be OR'd with x86_spec_ctrl_base, and letting the asm load x86_spec_crtl_base for itself (the variable itself would have to be exported). I'm inclined not to bother. It's not like it's even that much of a win because we *clobber* those registers anyway.