Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 27 Jul 2020 05:49:28 -0700
User-Agent: K-9 Mail for Android
In-Reply-To: <20200727083619.GF119549@hirez.programming.kicks-ass.net>
References: <20200727043132.15082-1-ricardo.neri-calderon@linux.intel.com> <20200727043132.15082-5-ricardo.neri-calderon@linux.intel.com> <D51F2DC3-3C56-44E6-A1F2-434E7D27133C@zytor.com> <20200727083619.GF119549@hirez.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PATCH 4/4] x86/cpu: Use SERIALIZE in sync_core() when available
To:     peterz@infradead.org
CC:     Ricardo Neri <ricardo.neri-calderon@linux.intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@kernel.org>, Borislav Petkov <bp@suse.de>,
        Andy Lutomirski <luto@kernel.org>, x86@kernel.org,
        Dave Hansen <dave.hansen@intel.com>,
        Tony Luck <tony.luck@intel.com>,
        Cathy Zhang <cathy.zhang@intel.com>,
        Fenghua Yu <fenghua.yu@intel.com>,
        Kyung Min Park <kyung.min.park@intel.com>,
        "Ravi V. Shankar" <ravi.v.shankar@intel.com>,
        Sean Christopherson <sean.j.christopherson@intel.com>,
        linux-kernel@vger.kernel.org,
        Ricardo Neri <ricardo.neri@intel.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        linux-edac@vger.kernel.org
From:   hpa@zytor.com
Message-ID: <49251CFA-8AC3-462D-A60F-0337593BE9CD@zytor.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On July 27, 2020 1:36:19 AM PDT, peterz@infradead=2Eorg wrote:
>On Sun, Jul 26, 2020 at 10:55:15PM -0700, hpa@zytor=2Ecom wrote:
>> For a really overenginered solution, but which might perform
>> unnecessary poorly on existing hardware:
>>=20
>> asm volatile("1: =2Ebyte 0xf, 0x1, 0xe8; 2:"
>>                         _ASM_EXTABLE(1b,2b));
>
>Ha! cute, you take an #UD ?
>
>We could optimize the #UD exception handler for this I suppose, but
>that
>makes it an even worse hack=2E The simple alternative() seems like a much
>simpler approach=2E

If this is in any way performance critical, then no :) Taking the #UD has =
the cute property that we end up IRET on the way back, so we don't even nee=
d a fix-up path=2E


--=20
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E