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;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andy Lutomirski <luto@amacapital.net>
Mime-Version: 1.0 (1.0)
Subject: Re: WARNING: can't access registers at asm_common_interrupt
Date:   Sun, 15 Nov 2020 08:05:55 -0800
Message-Id: <53DCD372-A847-4B74-A034-330E372B4EB5@amacapital.net>
References: <01c2234c-39a3-2227-25b9-854144c6eb27@suse.com>
Cc:     Andy Lutomirski <luto@kernel.org>,
        Andrew Cooper <andrew.cooper3@citrix.com>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>,
        linux-kernel@vger.kernel.org, Nicholas Piggin <npiggin@gmail.com>,
        Damien Le Moal <Damien.LeMoal@wdc.com>,
        X86 ML <x86@kernel.org>
In-Reply-To: <01c2234c-39a3-2227-25b9-854144c6eb27@suse.com>
To:     =?utf-8?Q?J=C3=BCrgen_Gro=C3=9F?= <jgross@suse.com>
Precedence: bulk


> On Nov 14, 2020, at 10:33 PM, J=C3=BCrgen Gro=C3=9F <jgross@suse.com> wrot=
e:
>=20
> =EF=BB=BFOn 14.11.20 19:10, Andy Lutomirski wrote:
>>> On Sat, Nov 14, 2020 at 1:16 AM J=C3=BCrgen Gro=C3=9F <jgross@suse.com> w=
rote:
>>>=20
>>> On 13.11.20 18:34, Andy Lutomirski wrote:
>>>> On Wed, Nov 11, 2020 at 12:25 PM Andrew Cooper
>>>> <andrew.cooper3@citrix.com> wrote:
>>>>=20
>>>> So I think there is at most one of these that wants anything more
>>>> complicated than a plain ALTERNATIVE.  Any volunteers to make it so?
>>>> Juergen, if you do all of them except USERGS_SYSRET64, I hereby
>>>> volunteer to do that one.
>>>=20
>>> Why is a plain alternative (either swapgs; sysretq or a jmp xen_sysret64=

>>> depending on X86_FEATURE_XENPV) no option?
>>>=20
>>> Its not as if this code would run before alternative patching.
>> ALTERNATIVE would "work" in the sense that it would function and be
>> just about as nonsensical as the current code.  Fundamentally, Xen
>> PV's sysret feature is not a drop-in replacement for SYSRET64, and
>> pretending that it is seems unlikely to work well.  I suspect that the
>> current code is some combination of exceedingly slow, non-functional,
>> and incorrect in subtle ways.
>> We should just have a separate Xen PV exit path the same way we have a
>> separate entry path in recent kernels.  *This* is what I'm
>> volunteering to do.
>=20
> I don't think there is much work needed. Xen PV does basically a return
> to user mode via IRET. I think it might work just to use
> swapgs_restore_regs_and_return_to_usermode() unconditionally for Xen PV.
>=20

I=E2=80=99m quite confident that will work, but I was hoping to get it to wo=
rk quickly too :)

>=20
> Juergen
> <OpenPGP_0xB0DE9DD628BF132F.asc>