EEL6892 Class Project
From Grid-Appliance Wiki
Contents |
Introduction
HOW-TO Author: Girish Venkatasubramanian, girish, Renato Figueiredo, renato
Overview: This document provides instructions for the students of EEL 6892 (Fall 2008) for the class project.
Pre-Requisites to using Simics on Archer
- This manual assumes that the user has signed up for an account on Simics Website. to access the very helpful message boards on the Simics website. Accounts can be obtained by applying at this link https://www.simics.net/register/register.php. It is not necessary to apply for a Personal Academic License as the Simics on Archer infrastructure will be used for the project.
- Three types of consoles are referred to in this document
- console means the normal shell
- Simics console means the shell in which simics is running, i.e. the shell with the simics command prompt
- Simulated console means the console of the simulated machine. Note that this is visible only for simulations running on the local grid appliance (not for remote jobs) and only if the -no-win option is not specified
- In this manual, all commands which are preceded by "simics >" have to be typed at the Simics command prompt i.e. in the Simics Console.
Setup Phase 1
The aim of this phase is to familiarize students with Simics and running simple Simics simulations on Archer.
- First, follow the steps 1 and 2 from Archer Express hands-on tutorial
- Register for Archer and download and setup the archer appliance by following the Archer Global tutorial.
- Once this step is successfully completed, the Simics documentation including user guides and reference manuals will be present in /opt/virtutech/simics-3.0.31/doc/
Setup Phase 2
The aim of this phase is to familiarize students with running Xen on Simics. The Xen® hypervisor, the powerful open source industry standard for virtualization, offers a powerful, efficient, and secure feature set for virtualization of x86, x86_64, IA64, PowerPC, and other CPU architectures. It supports a wide range of guest operating systems including Windows®, Linux®, Solaris®, and various versions of the BSD operating systems. More information about Xen can be found at the Xen Website.
For your convenience, a checkpoint (refer to Simics User Guide) has been prepared which has
- Booted Xen 3.0.2
- Two virtual machines ("domains" in the Xen terminology)
- A dom0 (management domain) with domid 0 and virtual IP 10.10.0.12
- A domU (user domain) with domid 3 and virtual IP 10.10.0.14
- SSH with RSA keys (no need of passwords) set up between the two domains
- Two workloads in each domain
- NBench - A linux/Unix port of BYTE which a CPU intensive benchmark. More information on this benchmark can be found at http://www.tux.org/~mayer/linux/bmark.html and http://www.byte.com/bmark/bmark.htm
- Compiling OpenAFS. OpenAFS is the open source version of the Andrew File System. More information about OpenAFS can be obtained http://www.openafs.org/
Xen has been compiled including Simics specific hooks to identify Domain Switches, TLB Flushes and Page Faults. A python script to catch these hooks has also been provided.
The checkpoint and the script can be accessed by mounting an NFS shared directory to a local mount point on your grid appliance, as follows:
cd /opt/virtutech/simics-3.0.31/ mkdir workspace /opt/virtutech/simics-3.0.31/bin/workspace-setup /opt/virtutech/simics-3.0.31/workspace cd workspace cd targets/x86-440bx ln -s ../../simics ln -s /mnt/ganfs/C124004016 local_mount
If the nfs exported local_mount directory has been mounted properly, you should see the following files inside local_mount (the small magic-hap-handler.py has the simulator 'hooks', and the large raw/craff files have the virtual disk and memory checkpoints for the Xen system):
local_mount/magic-hap-handler.py local_mount/checkpoint: xen-dom0-domU xen-dom0-domU-disk0_image-0.craff xen-dom0-domU-ram0_image-0.craff xen-dom0-domU.raw xen-dom0-domU-rom0_image-0.craff xen-dom0-domU-rom1_image-0.craff xen-dom0-domU-vga0_prom_image-0.craff xen-dom0-domU-vga0_vram_image-0.craff
Start up the simulation (on the your local grid appliance). The steps below accomplish the following goals:
- start Simics and load the checkpointed system image with the Xen hypervisor and two domains pre-booted and ready to run applicatoins
- load the Python script magic-hap-handler.py, which contains the hooks described above
- force a keyboard entry to the console that starts the execution of the nbench benchmark
- run the simulation for one million processor cycles
./simics -c local_mount/checkpoint/xen-dom0-domU simics > run-python-file local_mount/magic-hap-handler.py simics > con0.input "cd /root/nbench-byte-2.2.3; ./nbench -cCOM.DAT \n" simics > continue 1_000_000
(for details about con0.input, refer to the gfx-console in the Simics Reference Manual)
The details of the context switches happening will be displayed in the simics console and will look something like
Switching from 0 to 32767 at 392038941035 Switching from 32767 to 0 at 392038944797 Switching from 0 to 32767 at 392039305581 Switching from 32767 to 0 at 392039310973 Switching from 0 to 32767 at 392039669045 Switching from 32767 to 0 at 392039677251 [cpu0] cs:0xff149d27 p:0x00149d27 mov esi,dword ptr 16[esp]
Note that domain id 32767 is the "idle domain" similar to pid=0 in Linux.
By uncommenting different portions of the magic-hap-handler.py script, different events, like tlb flushes etc, can be tracked. The python script can also be modified so that these messages can be written to a file.
Questions
- Describe in one or two paragraphs what is the difference between Simics and a whole-system emulator.
- Describe briefly the difference between the Xen hypervisor and a Classic VM.
- What was the virtual IP address obtained for your Archer Global appliance?
- Run the Simics simulation for 20 million cycles. How many domain switches have you observed? How many cycles are executed in domain zero versus in the idle domain?
- Stop the simulation, exit Simics. Copy the python script to /opt/virtutech/simics-3.0.31/workspace/targets/x86-440bx/ and rename it as magic-hap-handler-modified.py. Edit this script to enable logging of TLB flushes and page fault events. Restart Simics and run the simulation for 20 million cycles. How many TLB flushes have you observed? Are they correlated with domain switches? Explain.
- Stop the simulation and exit Simics. Now you will run the nbench benchmark in both Xen domain 0 (dom0) and domain 3 (domU). To do this, you will need to change the con0.input sequence to start nbench in the background in dom0, and to ssh into domU (10.10.0.14) to run nbench there (as shown in the next section). Repeat the previous step, and analyze the results you obtained when two domains are active.
Helpful Tips
These tips show how to use some often used Simics commands. More information about these commands is in the Simics manual and the Simics message boards/discussion forums.
- When running for a large number of cycles, it is a good idea to write the messages to a file rather than the Simics console. To do this, the magic-hap-handler-modified.py script can be edited by replacing
print s
with
f=open('logfile','a')
f.write(s)
f.close()
- To use con0.input to start workloads on dom0 and domU
./simics -c local_mount/checkpoints/xen-dom0-domU simics > run-python-file local_mount/magic-hap-handler.py simics > con0.input "cd /root/nbench-byte-2.2.3; ./nbench -cCOM.DAT &\n" simics > con0.input "ssh 10.10.0.14 'cd /root/nbench-byte-2.2.3; echo Starting nbench; ./nbench -cCOM.DAT' \n" simics > c 900_000_000
At this point, nbench has started in both the domains.
- The default TLB model being simulated in the checkpoint is the ideal (no size limitations, fully associative) model. To change the model to a slightly more realistic one (64 entry - 4 way associative), use the command
simics > cpu0_tlb->type="normal" To change back to the ideal model, use simics > cpu0_tlb->type="unlimited"
- The contents of the TLB can be examined by using the command
simics > cpu0_tlb.status
- In order to read a CPU register (say CR3 register) we need to do two things
- Get the number of the register (54 for CR3)
- Read the register using the number
simics > @SIM_get_register_number(conf.cpu0, "cr3") 54 simics > @SIM_read_register(conf.cpu0, 54) 413675520
- To read the contents of a 4 byte memory word starting from an address (say 413675520)
simics > @SIM_read_phys_memory(conf.cpu0, 413675520, 4)
- The trace module is a Simics component which provides a trace of all the instructions and memory requested executed by the processor. To use the trace module the following steps have to be done
- Create the trace modules
- Start the trace module
- Continue the simulation and observe the trace
simics > new-tracer Trace object 'trace0' created. Enable tracing with 'trace0.start' simics > trace0.start Tracing enabled. Writing text output to standard output. simics > c 10
