Messages in this thread | | | Date | Sat, 3 Apr 2021 10:28:01 -0700 | From | Andi Kleen <> | Subject | Re: [RFC v1 00/26] Add TDX Guest Support |
| |
On Sat, Apr 03, 2021 at 09:26:24AM -0700, Dave Hansen wrote: > On 4/2/21 2:32 PM, Andi Kleen wrote: > >> 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. > > Well, not exactly. You still can't do things that will could cause a n > unbounded recusive #VE.
> It doesn't seem *that* far fetched to think that someone might try to > defer some work or dump data to the console.
I believe the main console code has reentry protection.
I'm not sure about early_printk (with keep), buf it that's the case it probably should be fixed anyways. I can take a look at that.
Not sure why deferring something would cause another #VE?
> > 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. > > >> 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. > > Do we need a TDX-specific earlyprintk? I would imagine it's pretty easy > to implement.
Don't see a need at this point, the existing mechanisms work.
Maybe if we ever have a problem that only happen in lockdown *and* happens early, but that's not very likely since lock down primarily changes code behavior later.
There are also other debug mechanisms for such cases: in TDX if you configure the TD for debug mode supports using the gdb stub on the hypervisor.
-Andi
| |