The goal of this experiment is to execute N periodic real-time threads
in a VM, scheduling its vCPU(s) with SCHED_DEADLINE and verifying that if
the correct (Q,P) parameters are used then no deadline is missed.

To do this, we need to:
1) Setup a KVM-based VM without having to waste some GBs of disk space and
   to install our favourite Linux distribution in the VM
2) Implement an application composed by N real-time threads having the
   desired periods and execution times
3) Execute the application of itme 2) in the VM of item 1)
4) Schedule the VM's vCPU thread(s) with SCHED_DEADLINE (we already know
   how to properly design Q and P!)
5) Check if any deadline is missed

For 1), we use the pre-compiled kernel and initramfs available from the
CBSD web site. The VM is based on QEMU, which uses the KVM kernel module
(creating 1 thread for each virtual CPU) and can be started with
	sh start_qemu.sh

For 2), we use the "periodic_thread" program that is already installed in
the provided initramfs (the source code is also available on the course web
site).
This program creates a set of periodic threads with given execution times
and periods. Each thread executes for a fixed amount of time using a busy
loop (counting from 0 to N), so the program must know how much to count
in order to consume a known amount of time. This is measured in a
"calibration" phase before starting the periodic threads (see cpu_consume.c).

For 3), we combine the solutions presented for 1) and 2). The only issue
is that the strategy used by "periodic_thread" to compute the number of
iterations per job works well only if the calibration loop is scheduled
with the highest priority in the system.
In particular, if the calibration is executed in a thread scheduled by a
(hard) CBS it is completely unreliable.
In that case, the "-R" command line option will have to be used (see the
handling of "cnt" in periodic_thread.c) after pre-computing the calibration
value.

Before starting the VM, one last thing: the CPU speed must be forced to
be a little bit more predictable and the "RT throttling" mechanism implemented
by the Linux scheduler must be disabled. To do so, type:
	sudo su
	cd /sys/devices/system/cpu/intel_pstate
	echo 1 > min_perf_pct
	echo 1 > max_perf_pct
	echo 1 > no_turbo
	echo -1 > /proc/sys/kernel/sched_rt_runtime_us
(note: writing "1" in *_perf_pct will slow down your CPU... If your
CPU is already slow, use a larger value - between 1 and 100. The
important thing is to make sure that min_perf_pct and max_perf_pct
contain the same value)

Now, tart the VM with "sh start_qemu.sh". In the guest, disable
RT throttling:
	sudo su
	echo -1 > /proc/sys/kernel/sched_rt_runtime_us
then, go to /Test ("cd /Test") and start a periodic taskset
("sh ts_parse.sh TSs/ts3.txt"). In the host, run "top -p <PID>", where
"PID" is the pid of the qemu instance you started (it is also printed
by "start_qemu.sh"), then press "H" (capital "H") and look at the thread
that is consuming more CPU time... This is the KVM's virtual CPU (vCPU)
thread (if you are lucky, it should be the thread with the id printed by
"start_qemu.sh" as "vCPU thread", but this really depends on the QEMU
version you are using --- so, do not rely on the "start_qemu.sh" output,
but use "top" to identify the correct thread).
This is the thread for which we need to set the scheduling parameters.
First of all, run it with the highest real-time priority, to calibrate
the CPU
        sudo chrt -p 99 <vCPU id>
   and restart the periodic threads in the VM:
        sh ts_parse.sh TSs/ts3.txt > log.txt

Look at the "Cycles = <nnn>" line in the program's output, and save the
"<nnn>" value somewhere.

Now, it is time to use SCHED_DEADLINE... Look at the "log.txt" file you
Open the "ts_parse.sh" file, search a commented "echo -n " -R xxxxx"
line and change "xxxxx" to the value you just saved. Then, uncomment
the line by removing the leading "#".
In the host, change the scheduling policy of the vCPU thread
	sudo chdl/chdl <vCPU id> 10000 15000
(notice: Qs and Ts are expressed in microseconds).
At this point, you can restart the periodic threads, saving the results:
	sh ts_parse.sh TSs/ts3.txt > log_rsv.txt
When the program finishes, look at the results in "log_rsv.txt".
The 4th columns indicates the response time for all the jobs J_{i,k}
(first column: task index i; second column: job index k) and the last
column is negative if the deadline is respected.
Check that all of the values are negative.

Now, try changing the periodic server parameters to something not
schedulable
	sudo chdl/chdl <vCPU id> 9000 15000
run the periodic threads again
	sh ts_parse.sh TSs/ts3.txt > log_rsv_bad.txt
and check that "log_rsv_bad.txt" contains some missed deadlines (positive
values in the last column).