Open Stack

Thanks for the quick reply!  My question wasn't specific to the
complexities of TDX though - sorry for any misunderstanding.

I'm just looking at the PRs starting with #3251, no really advanced
stuff, and I'm noticing that for the shim binary just to boot up, it's
necessary to have a socket and a namespace and a container bundle and a
kata config file - pointed to by either config.json of that bundle or
KATA_CONF_FILE - and an event publishing binary etc. etc.

So I'm just wondering, what do the shim developers do when they want to
watch the shim code executing?  Are there ways to mock or stub out the
interactions with environment, or is the full environment simply just
necessary?  If so, do people deploy it on their work machines, or do
they do development in a throw-away VM?

I'm interested in practical experience.  I basically know how achieve
what I'd like achieve, my question is about how to do it in a smart and
efficient way if possible.

Thanks!

	pvl


On Tue, Feb 15, 2022 at 02:27:59PM +0800, Jiang Liu wrote:
> 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
>