microsoft/openvmm
Publicmirrored from https://github.com/microsoft/openvmmAvailable
Guide/src/dev_guide/tests/vmm.md
125lines · modecode
| 1 | # VMM Tests |
| 2 | |
| 3 | ```admonish tip |
| 4 | Note: We recommend using [cargo-nextest](https://nexte.st/) to run unit / VMM |
| 5 | tests. It is a significant improvement over the built-in `cargo test` runner, |
| 6 | and is the test runner we use in all our CI pipelines. |
| 7 | |
| 8 | You can install it locally by running: `cargo install cargo-nextest --locked` |
| 9 | |
| 10 | See the [cargo-nextest](https://nexte.st/) documentation for more info. |
| 11 | ``` |
| 12 | |
| 13 | The OpenVMM repo contains a set of "heavyweight" VMM tests that fully boot a |
| 14 | virtual machine and run validation against it. Unlike Unit tests, these are all |
| 15 | centralized in a single top-level `vmm_tests` directory. |
| 16 | |
| 17 | The OpenVMM CI pipeline will run the full test suite; you'd typically run only |
| 18 | the tests relevant to the changes you're working on. |
| 19 | |
| 20 | ### Running VMM Tests |
| 21 | |
| 22 | ```admonish warning |
| 23 | `cargo nextest run` won't rebuild any of your changes. Make sure you `cargo build` |
| 24 | or `cargo xflowey igvm [RECIPE]` first! |
| 25 | ``` |
| 26 | |
| 27 | VMM tests are run using standard Rust test infrastructure, and are invoked via |
| 28 | `cargo test` / `cargo nextest`. |
| 29 | |
| 30 | ```bash |
| 31 | cargo nextest run -p vmm_tests [TEST_FILTERS] |
| 32 | ``` |
| 33 | |
| 34 | For example, to run a simple VMM test that simply boots using UEFI: |
| 35 | |
| 36 | ```bash |
| 37 | cargo nextest run -p vmm_tests x86_64::uefi_x64_frontpage |
| 38 | ``` |
| 39 | |
| 40 | And, for further example, to rebuild everything and run all the tests |
| 41 | (see below for details on these steps): |
| 42 | |
| 43 | ```bash |
| 44 | # Install (most) of the dependencies; cargo nextest run may tell you |
| 45 | # about other deps. |
| 46 | rustup target add x86_64-unknown-uefi |
| 47 | rustup target add x86_64-pc-windows-msvc |
| 48 | sudo apt install clang-tools-14 lld-14 |
| 49 | |
| 50 | cargo xtask guest-test download-image |
| 51 | cargo xtask guest-test uefi --bootx64 |
| 52 | |
| 53 | # Rebuild all, and run all tests |
| 54 | cargo build --target x86_64-pc-windows-msvc -p pipette |
| 55 | cargo build --target x86_64-unknown-linux-musl -p pipette |
| 56 | |
| 57 | cargo build --target x86_64-pc-windows-msvc -p openvmm |
| 58 | |
| 59 | cargo xflowey build-igvm x64-test-linux-direct |
| 60 | cargo xflowey build-igvm x64-cvm |
| 61 | cargo xflowey build-igvm x64 |
| 62 | |
| 63 | cargo nextest run --target x86_64-pc-windows-msvc -p vmm_tests |
| 64 | ``` |
| 65 | |
| 66 | #### \[Linux] Cross-compiling `pipette.exe` |
| 67 | |
| 68 | These commands might use the test agent (`pipette`) that is put inside the VM, |
| 69 | and if the host machine OS and the guest machine OS are different, a setup |
| 70 | is required for cross-building. The recommended approach is to use WSL2 and |
| 71 | cross-compile using the freely available Microsoft Visual Studio Build Tools |
| 72 | or Microsoft Visual Studio Community Edition as described in |
| 73 | [\[WSL2\] Cross Compiling from WSL2 to Windows](../getting_started/suggested_dev_env.md#wsl2-cross-compiling-from-wsl2-to-windows) |
| 74 | |
| 75 | If that is not possible, here is another option that relies on [MinGW-w64](https://www.mingw-w64.org/) |
| 76 | and doesn't require installing Windows: |
| 77 | |
| 78 | ```bash |
| 79 | # Do 1 once, do 2 as needed. |
| 80 | # |
| 81 | # 1. Setup the toolchain |
| 82 | rustup target add x86_64-pc-windows-gnu |
| 83 | sudo apt-get install mingw-w64-x86-64-dev |
| 84 | mingw-genlib -a x86_64 ./support/pal/api-ms-win-security-base-private-l1-1-1.def |
| 85 | sudo mv libapi-ms-win-security-base-private-l1-1-1.a /usr/x86_64-w64-mingw32/lib |
| 86 | |
| 87 | # 2. Build Pipette (builds target/x86_64-pc-windows-gnu/debug/pipette.exe first) |
| 88 | cargo build --target x86_64-pc-windows-gnu -p pipette |
| 89 | ``` |
| 90 | |
| 91 | ```bash |
| 92 | # Run a test |
| 93 | cargo nextest run -p vmm_tests x86_64::uefi_x64_windows_datacenter_core_2022_x64_boot |
| 94 | ``` |
| 95 | |
| 96 | #### Acquiring external dependencies |
| 97 | |
| 98 | Unlike Unit Tests, VMM tests may rely on additional external artifacts in order |
| 99 | to run. e.g: Virtual Disk Images, pre-built OpenHCL binaries, UEFI / PCAT |
| 100 | firmware blobs, etc... |
| 101 | |
| 102 | As such, the first step in running a VMM test is to ensure you have acquired all |
| 103 | external test artifacts it may depend upon. |
| 104 | |
| 105 | At this time, the VMM test infrastructure does not automatically fetch / rebuild |
| 106 | necessary artifacts. That said - test infrastructure is designed to report clear |
| 107 | and actionable error messages whenever a required test artifact cannot be found, |
| 108 | which provide detailed instructions on how to build / acquire the missing |
| 109 | artifact. |
| 110 | |
| 111 | |
| 112 | #### Printing logs for VMM Tests |
| 113 | |
| 114 | In order to see the OpenVMM logs while running a VMM test, do the following: |
| 115 | 1. Add the `--no-capture` flag to your `cargo nextest` command. |
| 116 | 2. Set `OPENVMM_LOG=trace`, replacing `trace` with the log level you want to view. |
| 117 | |
| 118 | ### Writing VMM Tests |
| 119 | |
| 120 | To streamline the process of booting and interacting VMs during VMM tests, the |
| 121 | OpenVMM project uses a in-house test framework/library called `petri`. |
| 122 | |
| 123 | The library does not yet have a stable API, so at this time, the best way to |
| 124 | learn how to write new VMM tests is by reading through the existing corpus of |
| 125 | tests, as well as reading through `petri`'s rustdoc-generated API docs. |