From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joerg Roedel Subject: Re: [PATCH 62/62] x86/sev-es: Add NMI state tracking Date: Wed, 12 Feb 2020 14:56:45 +0100 Message-ID: <20200212135645.GK20066@8bytes.org> References: <20200211135256.24617-1-joro@8bytes.org> <20200211135256.24617-63-joro@8bytes.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Andy Lutomirski Cc: X86 ML , "H. Peter Anvin" , Dave Hansen , Peter Zijlstra , Thomas Hellstrom , Jiri Slaby , Dan Williams , Tom Lendacky , Juergen Gross , Kees Cook , LKML , kvm list , Linux Virtualization , Joerg Roedel List-Id: virtualization@lists.linuxfoundation.org On Tue, Feb 11, 2020 at 02:50:29PM -0800, Andy Lutomirski wrote: > On Tue, Feb 11, 2020 at 5:53 AM Joerg Roedel wrote: > This patch is overcomplicated IMO. Just do the magic incantation in C > from do_nmi or from here: > > /* > * For ease of testing, unmask NMIs right away. Disabled by > * default because IRET is very expensive. > > If you do the latter, you'll need to handle the case where the NMI > came from user mode. > > The ideal solution is do_nmi, I think. > > if (static_cpu_has(X86_BUG_AMD_FORGOT_ABOUT_NMI)) > sev_es_unmask_nmi(); > > Feel free to use X86_FEATURE_SEV_ES instead :) Yeah, I also had that implemented once, but then changed it because I thought that nested NMIs do not necessarily call into do_nmi(), which would cause NMIs to stay blocked forever. I need to read through the NMI entry code again to check if that can really happen. Regards, Joerg