Create integration tests by leveraging the KVM selftests, from kernel/tools/testing/selftests/kvm. These integration tests should be updated with our tests. They will allow us to exercise code that was introduced by our kvm-introvirt patches to KVM.

The KVM selftests are very useful, because they allow us to use the same test binary:

• to run in host context, e.g. to test the KVM IOCTL handlers and interface
• to run in guest context, e.g. to test the expected state of the guest, within the guest, and to exercise VMEXIT handlers in the host.

Summary

Add support for kernel v5.15 on Ubuntu Jammy.

Acceptance Criteria

• The patch v5.15 should be able to be applied successfully
• The compilation should succeed without errors
• The runtime behavior should be tested

Existing problem

The current build system uses the git branch name for versioning or for targeting a specific kernel version.
This prevents us from using a "main" branch, or to target multiple kernel versions for the same kvm-introvirt patch.
Another issue with this approach is the growing number of branch names polluting git objects.

Solution / Summary

Rework the build system so that it can support a main branch and be able to target multiple kernel versions.

Acceptance Criteria

• A main branch should now be used
• A directory structure in patches will be used to support multiple patch sets for specific kernel versions .e.g ./patches/ubuntu/focal/5.4/5.4.0-130.146
  • New sub-directories should only be created to resolve patch conflicts. Symbolic links should reuse applicable patch sets on newer kernels.
• Patches should follow upstream repositories tags but an available-headers.txt file, listing the supported kernels, will be used to filter compatible builds, as header packages are not available for all kernels
• Docker should be used in order to build any kernel version on the current host
• Docker should be used to export the list of available headers for a distro
• The build script should provide:
  • The ability to build all supported kernel versions at once
  • The ability to build a module for a specific kernel version
  • The ability to update the list of supported headers
  • The ability to target a binary package, a source package, configuration only (apply patch)
• Update documentation to reflect changes

Implemented CI improvements to build the kvm-introvirt kernel module, and then install it in vagrant boxes for ci tests in IntroVirt lib repo.

• Vagrant Files:
  • ivkvm - runs a focal ubuntu virtual box to build the kvm-introvirt deb package and uploads it to the github action
  • ivkvmhost - builds a focal ubuntu virtual box that has kvm-introvirt installed, then it is packaged as a vagrant box, and uploaded to the github action.
  • ivkvmhostci - builds a virtual box based of ivkvmhost with extra packages installed, vagrant libvirt plugin, libvirtd, etc, then it is packaged as a vagrant box, and uploaded to the github action. this box is intended to be used to test the IntroVirt lib.

These vagrant boxes were uploaded out of band to my vagrant cloud

The current changes for this are located in my fork at branch ubuntu/focal/Ubuntu-5.4.0-135.152.
This was branched ubuntu/focal/Ubuntu-5.4.0-99.112, but should not be merged back into that branch through a Pull Request with the current branch kernel naming schema.

I think the best way to merge the changes is for the IntroVirt:kvm-introvirt repo to make a main branch off of ubuntu/focal/Ubuntu-5.4.0-99.112 to begin the directory kernel naming schema (instead of branch naming). These changes could be added with a pull request to the new main branch, and then adapted to the new kernel naming schema.

@chp-io does this sound right?

This repository could use a README - building it is not entirely straightforward, especially when building for a kernel that isn't explicitly supported.