Intel® System Studio components can be used for software development, analysis, and debug targeting workloads running inside virtualized guest OS. In many ways developing for a virtualized environment is only an extension of the concept of cross-development. Below are the main principles of using ISS components within a Virtual Machine or for code development intended to run inside a Virtual Machine. For complete information, read the article Using Intel® System Studio in a Virtual Machine Environment.

Using Intel® C++ Compiler in VM

Because the compiler is largely independent of architecture details beyond the available instruction set and assumptions about cache and register set availability at run-time, it is not seriously influenced by virtualization.

The items above are part of the core abstraction feature set of any virtual machine and thus the environment the compiler sees is not significantly different from the real hardware.

Working with the Intel® C++ Compiler targeting a guest OS is identical to using it for cross-development: the development machine being the development host and the guest OS inside the VM wrapper being the development target.

If you decide to use dynamic linking for your application or workload, use redistributable compiler runtime libraries available in the Intel® System Studio target package:

  • Windows* host:

    C:\Program Files (x86)\IntelSWTools\system_studio_201x.y.zzz\Targets\system_studio_target.tgz

  • Linux* Host:


For target deployment of a codebase into a guest OS, only a valid SSH connection (or adb connection in the case of Android*) with TCP-IP address forwarding into the virtual machine in question is needed. This is a standard feature for most virtual machines.

The only additional step is to ensure TCP/IP communication forwarding from inside the virtual machine and making the ip address of the virtual machine along with the port used for debug communication visible to the network as a whole.

Details on how to do this setup can be found on Wikibooks* (

Below is an outline of how to set up IP forwarding from your development host into a guest OS for QEMU* and KVM* based environments.

  1. Install QEMU*, the KQEMU* accelerator and bridge-utils

    $ su -

    $ yum install qemu bridge-utils

  2. Create the image for the guest OS. For best performance, install your guest OS to an image file. To create one, type:

    $ qemu-img create filename size[ M | G ]

    where filename is the name of your image, and size is the size of your image with the suffix 'M' (MB) or 'G' (GB) right after the number, no spaces.

    $ qemu-img create Linux.img 10G

  3. Configure network for your guest OS. Put the following contents into /etc/qemu-ifup:



    # script to bring up the device in QEMU in bridged mode


    # This script bridges eth0 and tap0. First take eth0 down, then bring it up with IP


    /sbin/ifdown eth0

    /sbin/ifconfig eth0 up


    # Bring up tap0 with IP, create bridge br0 and add interfaces eth0 and tap0


    /sbin/ifconfig tap0 promisc up

    /usr/sbin/brctladdbr br0

    /usr/sbin/brctladdif br0 eth0

    /usr/sbin/brctladdif br0 tap0


    # As we have only a single bridge and loops are not possible, turn spanning tree protocol off


    /usr/sbin/brctlstp br0 off


    # Bring up the bridge with IP and add the default route


    /sbin/ifconfig br0 up

    /sbin/route add default gw192.168.1.1

    #stop firewalls

    /sbin/service firestarter stop

    /sbin/service iptables stop

    The bold values can be changed. Change the IPs to show your setup. The first bold is a comment, the second bolded value is the IP assigned to your computer, and the third is your gateway. Now, put this into /etc/qemu-ifdown:



    # Script to bring down and delete bridge br0 when QEMU exits


    # Bring down eth0 and br0


    /sbin/ifdown eth0

    /sbin/ifdown br0

    /sbin/ifconfig br0 down


    # Delete the bridge


    /usr/sbin/brctldelbr br0


    # bring up eth0 in "normal" mode


    /sbin/ifup eth0

    #start firewalls again

    /sbin/service firestarter start

    /sbin/service iptables start

    Make the scripts executable so QEMU can use them:

    $ su -

    $ chmod +x /etc/qemu-if*

    $ exit

Using Performance Libraries in VM

The statements made in the previous chapter about the Intel® C++ Compiler not being sensitive to the virtualization environment are exactly true for

  • Intel® Integrated Performance Primitives

  • Intel® Math Kernel Library

  • Intel® Threading Building Blocks

When using dynamic linking for these libraries, be aware of any redistributable runtime libraries you need. Consult the respective library user guides for details.

Using Intel® VTune™ Amplifier for Systems in VM

Intel® VTune™ Amplifier for Systems supports three classes of sampling methods.

  1. Dynamic binary instrumentation-based data collection for hotspot analysis, locks & waits analysis.

  2. Support for FTrace and Perf-based sampling data

  3. Event-based sampling and sampling with callstacks data collection

Event-based sampling is generally not supported with virtual environments.

Dynamic binary instrumentation-based data collection

The Intel® VTune™ Amplifier basic hotspot analysis without architectural event support, lock&wait analysis, and concurrency analysis work inside a virtual machine exactly the same way as they would outside of a virtual environment.

Use either ./amplxe-cl or ./amplxe-gui inside of a virtual machine for the sampling methods listed above without any problems.

However, SSH (or adb in the case of Android) based remote sampling will not work, as it relies on the use of the performance monitoring unit (PMU) on the target platform. The PMU is however generally not fully virtualized.

Refer to the Intel® VTune™ Amplifier for Systems User Guide for additional information on binary instrumentation-based hotspot, lock&wait, and concurrency analysis.

Event-based sampling

The general approach of exposing architectural performance events inside a QEMU-based virtual machine is to map these events to equivalent perf events.

This however poses two problems for event-based sampling using the SEP Sampling Collector, VTune™ Amplifier for Systems or the ssh/adb-based remote sampling collection.

First, the Intel® VTune™ Amplifier for Systems tries to access the PMU directly and expects responses that are not covered by the Perf mapping.

Second, there are many events that can be sampled and are selected by standard features like General Exploration that are not covered by this kind of high-level PMU virtualization as implemented with QEMU.

If you have full control of your virtual machine and can implement your own PMU virtualization and event export routines, you may want to consult the Performance Monitoring Unit Sharing Guide for more details on the supported architectural events.

Using FTrace or Perf with Intel® VTune™ Amplifier for Systems

Intel® VTune™ Amplifier for Systems has a new feature to put events on the timeline. It allows users of VTune Amplifier to draw correlations between code running on the CPU (and other data collected by VTune Amplifier), and events spawned by Linux* and Android* OS frameworks.

Data collected by native Linux* performance sampling methods like FTrace and Perf that do not depend on direct PMU access can be read into the Intel® VTune™ Amplifier for Systems following the instructions in the External Data Import chapter of the Intel® VTune™ Amplifier User Guide

All that is then required is to have FTrace enabled in the Linux* or Android* OS build of your virtualized guest OS.

Using Intel-enhanced GNU* GDB to debug applications running inside a virtual machine

All Intel-enhanced GDB features except for BTS (Branch Trace Storage)-based process-specific instruction trace, are available when debugging an application running inside a virtual machine.

For cross-development, GDB comes with a remote debug agent gdbserver. This debug agent can be installed on the debug target to launch a debuggee and attach to it remotely from the development host.

This can be useful in situations where the program needs to be run on a target host that is different from the host used for development, particularly when the target has a limited amount of resources (either CPU and/or memory).

To do so, start your program using gdbserver on the target machine. gdbserver then automatically suspends the execution of your program at its entry point, waiting for a debugger to connect to it. The following commands start an application and tell gdbserver to wait for a connection with the debugger on localhost port 2000.

$ gdbserver localhost:2000 program

Process program created; pid = 5685

Listening on port 2000

Once gdbserver has started listening, we can tell the debugger to establish a connection with this gdbserver, and then start the same debugging session as if the program was being debugged on the same host, directly under the control of GDB.

$ gdb program

(gdb) target remote targethost:4444

Remote debugging using targethost:4444

0x00007f29936d0af0 in ?? () from /lib64/

(gdb) b foo.adb:3

Breakpoint 1 at 0x401f0c: file foo.adb, line 3.

(gdb) continue


Breakpoint 1, foo () at foo.adb:4

4 end foo;

It is also possible to use gdbserver to attach to an already running program, in which case the execution of that program is simply suspended until the connection between the debugger and gdbserver is established. To tell gdbserver to wait for GDB to attempt a debug connection to the running process with process ID 5685, use the following syntax:

$ gdbserver localhost:2000 --attach 5685

Using GDB for remotely debugging an application running inside a virtual machine follows the same principle as remote debug using the gdbserver debug agent.

The only additional step is to ensure TCP/IP communication forwarding from inside the virtual machine and making the ip address of the virtual machine along with the port used for debug communication visible to the network as a whole.

Details on how to do this setup can be found on Wikibooks* (

The basic steps are here plus:

  1. Install the guest OS. Type the following to start the installation:

    $ su

    $ /sbin/modprobetun

    $ qemu -boot d -hdaimage.img -localtime -net nic -net tap -m 192 -usb -soundhw sb16 -cdrom /dev/hdc;/etc/qemu-ifdown

    whereimage.img is the name you gave to your image earlier. It is assumed that /dev/cdrom is your CD drive. If it is not, then change it to the correct device. After the install is complete, proceed to step 5.

  2. Create the QEMU start script and from there on you can run your guest OS. Create this file - called qemustart - in the same directory as your image:


    su -c "/sbin/modprobetun;qemu -boot c -hdaimage.img -localtime -net nic -net tap -m 192 -usb -soundhw sb16;/etc/qemu-ifdown"

    where image.img was the name given to the image earlier

  3. Make the startup script executable:

    $ chmod +x /path/to/qemustart

Intel® Inspector

Intel® Inspector dynamically instruments the application to be analyzed and does not interact directly with any underlying hardware features. It is therefore possible to simply use ./inspxe-cl or ./inspxe-gui natively launched on the guest OS.

Note that the Intel® Inspector for Systems does not support real-time scheduler patches with Linux*.

For more complete information about compiler optimizations, see our Optimization Notice.