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
