Open Stack

It’s hard to debug firmware code, and it’s even harder to debug TDX firmware code:)

I have tried to improve the development experience for td-shim. Some enhancements have been merged into td-shim:
1) Test td-shim components on host as much as possible. Some td-shim components are generic enough, we could test on host side instead of inside an TDX env.
2) For code must be run inside an VM, split them TDX dependent and TDX independent parts. A cargo feature named “tdx” has been used to mark TDX specific code.
But there’s still one step left, enhancing the td-shim/ResetVector to support booting from non-tdx environment. The TDX defines a special power-up context, and the td-shim/ResetVector only support booting from TDX context. So the td-shim/ResetVector should be enhanced to support booting from normal context, and I think that’s doable:)

With the last step done, we could boot and debug a td-shim with qemu, though TDX is disabled. 

> On Feb 15, 2022, at 1:10 AM, Pavel Mores <pmores at redhat.com> wrote:
> 
> 
> Hi all,
> 
> I'm looking into the Rust shim PRs (great job!) and I'd like to be able
> reasonably easily to run the binary standalone, preferrably under
> debugger, mostly to verify my assumptions.
> 
> I noticed the binary is somewhat hard to run though - it has complex
> interactions with its environment and makes quite a lot of assumptions
> about it.  I was wondering if there's a way to mock these, or how shim
> developers go about debugging and verifying the code.
> 
> Thanks in advance!
> 
> 	pvl
> 
> 
> _______________________________________________
> kata-dev mailing list
> kata-dev at lists.katacontainers.io
> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev