Exercise Objectives and Logistics
Overview
The objective of this exercise is to develop a simple emulated device in the Qemu virtual machine monitor, to develop the guest driver controlling that device in the Linux kernel, and to write a small guest user space application making use of the device through the driver. The emulated device is a simple random number generator (RNG).
The different software components you will have to develop are illustrated in green on the figure below:
The components to develop are:
- The emulated device running on the host within Qemu.
- A driver for the device running within the guest operating system, Linux.
- A user space application leveraging the driver to make use of the device.
Random Number Generator Virtual Device
Our virtual RNG device offers two functionalities:
- Generating random numbers: applications can query the virtual device through a driver in the guest kernel to obtain random numbers.
- Seeding the RNG: applications can initialise the RNG with a particular seed.
The random number generator will be connected to the VM's virtual CPU on the PCI bus, and communication between the device and the CPU will be achieved with memory mapped I/O registers. To function the devices exposes an interface made of two registers, illustrated below:
You can find more information about the registers in the table below.
| Register name | Offset from base address | Size | Mode (R/W) | Description |
|---|---|---|---|---|
RNG | 0x0 | 4 bytes | R | Reading this register returns a random number in the form of a 32 bits unsigned integer. Each new read returns a new random number. |
SEED | 0x4 | 4 bytes | W | Writing an unsigned 32 bits number to this register seeds the random number generator with that value. |
Exercise Structure
This exercise will be in 2 parts: the first part represents most of this guide, which is a tutorial that will hold your hand to develop a basic version of the software presented on the figure above. Accomplishing this first part will get you a part of the marks for this exercise (12/20). The second part is open-ended: you will be asked to enhance the basic prototype developed (some suggestions will be given, but you can also decide to implement your own enhancements). That part will count for the rest of the marks (8/20). Along with your code you should submit a short, 2-page report, describing the enhancement(s) you develop, and how they can be tested.
Deadline and Submission Format
The deadline for submitting this exercise is 23/01/2024. In case of late submission, a penalty of 10% for each day late will be applied to the final mark.
To submit you should send the following things items by email to the instructor (pierre.olivier <at> manchester.ac.uk):
- A patch, corresponding to your implementation of the virtual device, that can be applied to Qemu's vanilla source code v8.2.0-rc2.
- Another patch, corresponding to your implementation of the virtual device's driver, that can be applied to Linux's vanilla source code v6.6.4.
- The 2-page report describing your enhancements and how to test that they are functional.
Guidance on how to generate the patches will be given at the end of this tutorial.
Marking Scheme
The exercise is marked out of a total of 20.
Part 1: guided tutorial /12
- Device: the Qemu patch applies without errors/warnings to the vanilla sources of Qemu v8.2.0-rc2 /1.
- Device: a small test from the Linux kernel boot process repeatedly seeding the device with the same value yields similar random number sequences /3.
- Device: the implementation of the read/write mmio function follows the device's specifications (proper register addresses and sizes used) /2.
- Driver: the Linux patch applies without errors/warnings to the vanilla sources of linux v6.6.4 /1.
- Driver: a small test after creation of the virtual file from a user space application using the driver to repeatedly seed the RNG with the same value yields similar random number sequences /3.
- Driver: data is transferred safely between user and kernel space /2.
Part 2: going further /8
- The report is clear about what enhancements were developed and how to test them /3.
- The enhancements are functional/degree of ambition of the enhancements /5.