Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
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: [PATCH v2] x86/kvm: Disable KVM_ASYNC_PF_SEND_ALWAYS
Date:   Mon, 6 Apr 2020 13:42:28 -0700
Message-Id: <FFD7EE84-05FB-46E4-8CA5-18DD49081B5B@amacapital.net>
References: <6875DD55-2408-4216-B32A-9487A4FDEFD8@amacapital.net>
Cc:     Vivek Goyal <vgoyal@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Andy Lutomirski <luto@kernel.org>,
        Paolo Bonzini <pbonzini@redhat.com>,
        LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
        kvm list <kvm@vger.kernel.org>, stable <stable@vger.kernel.org>
In-Reply-To: <6875DD55-2408-4216-B32A-9487A4FDEFD8@amacapital.net>
To:     Peter Zijlstra <peterz@infradead.org>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Apr 6, 2020, at 1:32 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>=20
> =EF=BB=BF
>> On Apr 6, 2020, at 1:25 PM, Peter Zijlstra <peterz@infradead.org> wrote:
>>=20
>> =EF=BB=BFOn Mon, Apr 06, 2020 at 03:09:51PM -0400, Vivek Goyal wrote:
>>>> On Mon, Mar 09, 2020 at 09:22:15PM +0100, Peter Zijlstra wrote:
>>>>> On Mon, Mar 09, 2020 at 08:05:18PM +0100, Thomas Gleixner wrote:
>>>>>> Andy Lutomirski <luto@kernel.org> writes:
>>>>>=20
>>>>>>> I'm okay with the save/restore dance, I guess.  It's just yet more
>>>>>>> entry crud to deal with architecture nastiness, except that this
>>>>>>> nastiness is 100% software and isn't Intel/AMD's fault.
>>>>>>=20
>>>>>> And we can do it in C and don't have to fiddle with it in the ASM
>>>>>> maze.
>>>>>=20
>>>>> Right; I'd still love to kill KVM_ASYNC_PF_SEND_ALWAYS though, even if=

>>>>> we do the save/restore in do_nmi(). That is some wild brain melt. Also=
,
>>>>> AFAIK none of the distros are actually shipping a PREEMPT=3Dy kernel
>>>>> anyway, so killing it shouldn't matter much.
>>>=20
>>> It will be nice if we can retain KVM_ASYNC_PF_SEND_ALWAYS. I have anothe=
r
>>> use case outside CONFIG_PREEMPT.
>>>=20
>>> I am trying to extend async pf interface to also report page fault error=
s
>>> to the guest.
>>=20
>> Then please start over and design a sane ParaVirt Fault interface. The
>> current one is utter crap.
>=20
> Agreed. Don=E2=80=99t extend the current mechanism. Replace it.
>=20
> I would be happy to review a replacement. I=E2=80=99m not really excited t=
o review an extension of the current mess.  The current thing is barely, if a=
t all, correct.

I read your patch. It cannot possibly be correct.  You need to decide what h=
appens if you get a memory failure when guest interrupts are off. If this ha=
ppens, you can=E2=80=99t send #PF, but you also can=E2=80=99t just swallow t=
he error. The existing APF code is so messy that it=E2=80=99s not at all obv=
ious what your code ends up doing, but I=E2=80=99m pretty sure it doesn=E2=80=
=99t do anything sensible, especially since the ABI doesn=E2=80=99t have a s=
ensible option.

I think you should inject MCE and coordinate with Tony Luck to make it sane.=
 And, in the special case that the new improved async PF mechanism is enable=
d *and* interrupts are on, you can skip the MCE and instead inject a new imp=
roved APF.

But, as it stands, I will NAK any guest code that tries to make #PF handle m=
emory failure. Sorry, it=E2=80=99s just too messy to actually analyze all th=
e cases.=