[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210402213219.GM1285835@tassilo.jf.intel.com>
Date: Fri, 2 Apr 2021 14:32:19 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Andy Lutomirski <luto@...nel.org>,
Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
Dan Williams <dan.j.williams@...el.com>,
Raj Ashok <ashok.raj@...el.com>,
Sean Christopherson <seanjc@...gle.com>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC v1 00/26] Add TDX Guest Support
> If we go this route, what are the rules and restrictions? Do we have to
> say "no MMIO in #VE"?
All we have to say is "No MMIO in #VE before getting thd TDVEINFO arguments"
After that it can nest without problems.
If you nest before that the TDX will cause a triple fault.
The code that cannot do it is a few lines in the early handler which
runs with interrupts off.
The TDX module also makes sure to not inject NMIs while we're in
that region, so NMIs are of no concern.
That was the whole point of avoiding the system call gap problem. We don't
need to make it IST, so it can nest.
I'm not aware of any other special rules.
> Which brings up another related point: How do you debug TD guests? Does
> earlyprintk work?
Today it works actually because serial ports are allowed. But I expect it to
be closed eventually because serial code is a lot of code to audit.
But you can always disable the filtering with a command line option and
then it will always work for debugging.
-Andi
Powered by blists - more mailing lists