Received-SPF: pass (google.com: domain of linux-kernel+bounces-60495-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
From: David Laight <David.Laight@ACULAB.COM>
To: 'Sean Christopherson' <seanjc@google.com>, Linus Torvalds
	<torvalds@linux-foundation.org>
CC: Nick Desaulniers <ndesaulniers@google.com>, Uros Bizjak
	<ubizjak@gmail.com>, Jakub Jelinek <jakub@redhat.com>, "Andrew Pinski (QUIC)"
	<quic_apinski@quicinc.com>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, Masahiro Yamada <masahiroy@kernel.org>,
	"Peter Zijlstra" <peterz@infradead.org>, "kvm@vger.kernel.org"
	<kvm@vger.kernel.org>
Subject: RE: [PATCH] Kconfig: Explicitly disable asm goto w/ outputs on gcc-11
 (and earlier)
Thread-Topic: [PATCH] Kconfig: Explicitly disable asm goto w/ outputs on
 gcc-11 (and earlier)
Thread-Index: AQHaW6GAqckjYnd4VEGhBeXgBOKGT7ED0v0Q
Date: Sat, 10 Feb 2024 17:21:45 +0000
Message-ID: <9ba89b70e48143a69f76f6e0f276f149@AcuMS.aculab.com>
References: <20240208220604.140859-1-seanjc@google.com>
 <CAKwvOdk_obRUkD6WQHhS9uoFVe3HrgqH5h+FpqsNNgmj4cmvCQ@mail.gmail.com>
 <DM6PR02MB40587AD6ABBF1814E9CCFA7CB84B2@DM6PR02MB4058.namprd02.prod.outlook.com>
 <CAHk-=wi3p5C1n03UYoQhgVDJbh_0ogCpwbgVGnOdGn6RJ6hnKA@mail.gmail.com>
 <ZcZyWrawr1NUCiQZ@google.com>
 <CAKwvOdmKaYYxf7vjvPf2vbn-Ly+4=JZ_zf+OcjYOkWCkgyU_kA@mail.gmail.com>
 <CAHk-=wgEABCwu7HkJufpWC=K7u_say8k6Tp9eHvAXFa4DNXgzQ@mail.gmail.com>
 <CAHk-=wgBt9SsYjyHWn1ZH5V0Q7P6thqv_urVCTYqyWNUWSJ6_g@mail.gmail.com>
 <ZcadTKwaSvvywNA9@google.com>
In-Reply-To: <ZcadTKwaSvvywNA9@google.com>
Accept-Language: en-GB, en-US
Precedence: bulk
MIME-Version: 1.0
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

From: Sean Christopherson
> Sent: 09 February 2024 21:47
>=20
> On Fri, Feb 09, 2024, Linus Torvalds wrote:
> > Sean? Does this work for the case you noticed?
>=20
> Yep.  You can quite literally see the effect of the asm("").  A "good" se=
quence
> directly propagates the result from the VMREAD's destination register to =
its
> final destination
>=20
>   <+1756>:  mov    $0x280e,%r13d
>   <+1762>:  vmread %r13,%r13
>   <+1766>:  jbe    0x209fa <sync_vmcs02_to_vmcs12+1834>
>   <+1768>:  mov    %r13,0xe8(%rbx)
>=20
> whereas the "bad" sequence bounces through a different register.
>=20
>   <+1780>:  mov    $0x2810,%eax
>   <+1785>:  vmread %rax,%rax
>   <+1788>:  jbe    0x209e4 <sync_vmcs02_to_vmcs12+1812>
>   <+1790>:  mov    %rax,%r12
>   <+1793>:  mov    %r12,0xf0(%rbx)
..

Annoying, but I doubt it is measurable in this case.
Firstly it could easily be a 'free' register rename.
Secondly isn't vmread horribly slow anyway, so an extra
clock or two won't matter?

The double register move that OPTIMER_HIDE_VAR() often
generates is another matter entirely :-)
In the old days the peephole optimiser would (should?)
have removed most of these.

=09David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1=
PT, UK
Registration No: 1397386 (Wales)