The Bride: [Japanese] I need Japanese steel.
Hattori Hanzo: [Japanese] Why do you need Japanese steel?
The Bride: [Japanese] I have vermin to kill.
Hattori Hanzo: [English] You must have big rats if you need Hattori Hanzo's steel.
The Bride: [English] ... Huge.
(from Kill Bill: Vol. 1)
I will probably need the help of a therapist to assist me in decoding why I think of that passage from Tarantino's great movie whenever I think of our portfolio of multicore development tools. When I ponder the personality of our development tools (i.e. the fearless Hattori Hanzo
and his sword) and the risks presented to our customers in getting their multicore software to be correct (i.e. vermin - in reference to the challenges and bugs, not our customers) the exchange works for me.
We just announced a new release
that extends our capabilities for multicore and virtualization for embedded applications. As always, I'm very proud of our development tools engineering team. A special shout-out to our teams in Canton and Vannes for their efforts in delivering this release.
Last week, my colleague - Bill "The Truth" Graham - blogged about the importance of development tools in reducing the inherent complexity
of the task at hand. This latest release - actually, two product releases - is special because we have extended our hypervisor support to support Intel Xeon processors AND we have extended our development tools capabilities to now include "hypervisor-aware" debugging with our JTAG debuggers.
Why do I think this is important?
My mind goes back to a conversation with one of our early adopters of our hypervisor technology. The folks we met with were responsible for developing and stabilizing the software platform. The hypervisor technology is a critical component of their project as they are looking to consolidate multiple processors onto a single multicore device. They depend on our technology for memory protection to ensure the reliability of their system. One of the clearest memories I have from that day was when they asked "how do I debug my system running on the hypervisor"? The question was not asked out of curiousity - in their situation having assurances that we could address their needs in this area was critical for success.
So, what have done to help Kill Bugs when using virtualization?
The latest release of our Wind River On-Chip Debugging solutions enables debugging of a system running on the hypervisor without the need to add a target resident agent (see Figure 1). This new capability helps developers with tools to develop and debug hardware initialization code, virtual board bring-up, kernels, and drivers. When developing software for virtualized systems, these solutions give developers the confidence to know that they can set breakpoint, watch memory, or analyze stack frames.
Figure 1 - Overview of Hypervisor-aware debugging using Wind River On-Chip Debugging [click to enlarge]
This capability borrows from the concepts applied when debugging Linux processes using a JTAG debugger, but extends them to include the concepts of virtual boards running on the hypervisor. One of the special attributes of our solution is that we go beyond the MMU support provided by the processor to provide visibility and control over all of the virtual boards running on the system - not just the instance that is currently executing.
There's much more that can be discussed on this topic. More information and videos can be found here and there on our site. More importantly, we would like to hear your views on how to Kill Bugs when developing virtualized systems.