[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5b6b1937-d38f-a337-0520-7ce5d3083065@intel.com>
Date: Thu, 13 May 2021 13:07:35 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Andi Kleen <ak@...ux.intel.com>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Andy Lutomirski <luto@...nel.org>,
Dan Williams <dan.j.williams@...el.com>,
Tony Luck <tony.luck@...el.com>
Cc: Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
Raj Ashok <ashok.raj@...el.com>,
Sean Christopherson <seanjc@...gle.com>,
linux-kernel@...r.kernel.org,
Sean Christopherson <sean.j.christopherson@...el.com>
Subject: Re: [RFC v2 08/32] x86/traps: Add #VE support for TDX guest
On 5/13/21 12:47 PM, Andi Kleen wrote:
> "if there is any reason for it to nest the TD would shut down."
The TDX EAS says:
> If, when attempting to inject a #VE, the Intel TDX module discovers
> that the guest TD has not yet retrieved the information for a
> previous #VE (i.e., VE_INFO.VALID is not 0), the TDX module injects a
> #DF into the guest TD to indicate a #VE overrun.
How does that result in a shut down?
Powered by blists - more mailing lists