Date:   Wed, 29 Dec 2021 17:07:34 +0000
From:   Sean Christopherson <seanjc@google.com>
To:     Borislav Petkov <bp@alien8.de>
Cc:     "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        tglx@linutronix.de, mingo@redhat.com, dave.hansen@intel.com,
        luto@kernel.org, peterz@infradead.org,
        sathyanarayanan.kuppuswamy@linux.intel.com, aarcange@redhat.com,
        ak@linux.intel.com, dan.j.williams@intel.com, david@redhat.com,
        hpa@zytor.com, jgross@suse.com, jmattson@google.com,
        joro@8bytes.org, jpoimboe@redhat.com, knsathya@kernel.org,
        pbonzini@redhat.com, sdeep@vmware.com, tony.luck@intel.com,
        vkuznets@redhat.com, wanpengli@tencent.com, x86@kernel.org,
        linux-kernel@vger.kernel.org,
        Sean Christopherson <sean.j.christopherson@intel.com>
Subject: Re: [PATCH 04/26] x86/traps: Add #VE support for TDX guest
Message-ID: <YcyV1uwa72vhPXPV@google.com>
References: <20211214150304.62613-1-kirill.shutemov@linux.intel.com>
 <20211214150304.62613-5-kirill.shutemov@linux.intel.com>
 <YcTR5HnkHi7CjVyx@zn.tnic>
 <20211228233112.cpycmdv55edxhvbv@black.fi.intel.com>
 <YcxGrw6Ymqs8NPjY@zn.tnic>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YcxGrw6Ymqs8NPjY@zn.tnic>
Precedence: bulk

On Wed, Dec 29, 2021, Borislav Petkov wrote:
> On Wed, Dec 29, 2021 at 02:31:12AM +0300, Kirill A. Shutemov wrote:
> What I read is:
> 
> "Interrupts, including NMIs, are blocked by the hardware starting with
> #VE delivery until TDGETVEINFO is called."

FWIW, virtual/guest NMIs are blocked by the TDX module until pending #VE info
is retrieved via TDGETVEINFO.  Hardware has nothing to do with that behavior.

> but this simply means that *if* you get a #VE anywhere, NMIs are masked
> until TDGETVEINFO.

Yep.

> If you get a #VE during the NMI entry code, then you're toast...

Yes?  The rules would be the same as whatever existing rules we have for taking
#DBs in NMI, but that's because the subsequent IRET unblocking NMIs, not because
there's anything special about #VE.  Pending NMIs are blocked by the regular NMI
status (unblocked by IRET) _and_ by an unread #VE info.

The unread #VE info clause in NMI blocking is purely to prevent an NMI from being
injected before the guest's #VE handler can do TDGETVEINFO, otherwise a #VE at
_any_ point in the NMI handler would be fatal due to it clobbering the unread #VE
info (it'd be a similar problem to SEV-ES's GHCB juggling).