The “Simics Agent” – Automating Tasks in the Target from the Outside (with Video)

Automating tasks on a target system is an important aspect of virtual platform usage. There are many ways to do automation with Simics, and more are being added. Quite recently, we added a new feature, the Simics Agent, to help users automate tasks and upload software and tests to their target systems, as shown in a demo video.

The Simics Agent sits inside the target system software stack, and allows Simics to upload and download files, check the contents of the target file system, and issue commands to the target software and operating system – without having to script the target serial consoles or other target inputs. It makes automation easier to achieve, since you get more robust control over actions inside the target system. The principle is shown in the picture below. The Simics Agent simply calls the target OS to get commands executed invisibly to other software and the serial consoles. This also means that it is possible to control a target that does not have any exposed or open serial ports, Ethernet connections, or other general purpose IO. It does not even have to have a live shell – as long as the target OS has an API to issue commands, the agent can work with that.

While it is true that significant value comes from having a virtual platform that runs absolutely unmodified target software stacks, there are many cases where it is better to change the target software just a little bit to enable users to work more efficiently. For many development and testing tasks, such streamlining is very valuable, and the intrusive effect of running an agent on the target is negligible. The new Simics Agent is an example of such a system.

The primary purpose of the Simics Agent is to make it easier to move files and software onto and off of a target system. This is a very common problem with any virtual or physical platform – just how do you get the software you want to run onto it, and how do you collect output files from it? In many cases, the solution is to deploy software just like the real system does it, but in other cases, it is better to use a method that provides fast turn-around time that would not be possible in the physical system (see my previous blog post on automation with Simics for some of the alternatives). In particular for the case that we are interested in individual applications on a stable and given operating system, or injecting a dynamically loaded kernel module, it makes a lot of sense to use an agent of some kind to get newly compiled system into the target system.

If we look at virtual machine solutions in general, they universally provide some form of special drivers or agents to make it easier to work with the target systems. For example, VmWare and VirtualBox provide tools that you install on the target system to enable things like efficient file sharing with the host and mouse and keyboard capture. The Simics Agent is the same concept applied to Simics.

One of the main advantages of the agent as it is implemented is that it requires absolutely no change to the target hardware to perform its work.  The picture above shows that , there is no need for a special device and special device driver to move files into the target system, as was the case with our old trusty “simicsfs” solution. Instead, the agent relies on magic instructions that work at the user level of the target system. The Simics agent is a user-level program that communicates with the Simics simulator via magic instructions – this makes it very easy to port to a new system, and it can effectively punch through layers of hypervisors and operating systems since it does not need to get down to memory-mapped devices in hardware.

Another benefit of the Agent is that it can be controlled entirely from Simics. There is no need to enter commands on the target command-line. When using features like ftp or nfs to the host or to a service node in the simulated network, it is necessary to inject commands on the target system via its command-line. That does require the target to have a command-line system, and for it to be available when the scripting is happening. With the agent, it gets commands over the back door too, requiring no interactivity to be present. The Agent can send commands to the software in the target system, by calling the host OS API directly. This makes it more robust and more convenient. It also redirects output back to Simics, so that output from actions taken by the agent is visible in the Simics command line and not on the target command line.

The Simics Agent user-level process can be terminated to minimize target system intrusiveness. For example, the Simics Agent could be used to load software and test files onto a target system, and then quit. At this point, there is nothing on the target system except a small extra binary in the file system. There is nothing running that could disturb the target software, even theoretically.

In conclusion, what we have here is a good example that making a software stack just a little aware that it is running on a simulator can reap big dividends in simulator usability. In some cases, it is much simpler to do things with a man on the inside – and the Simics Agent gives Simics that insider angle.

Further information:

• To see the agent in action, please look at the video we have made available on Youtube, in the Wind River channel.
• For a really deep discussion about how to work efficiently with virtual platforms, please see chapter 3 of the book about simulation we published last year.
• More on Simics.