Add Guest MSR validation tests

[alsrdn]

trafficstars

Reason for This PR

Add a test to validate MSRs that are available to the Guest.

Description of Changes

This test boots a Firecracker uVM and tries to read a set of MSRs from the guest. The Guest MSR list is compared against a list of MSRs that are expected when running on a particular host kernel and with a particular Guest CPU template. The list is different for each kernel version because Firecracker relies on MSR emulation provided by KVM. If KVM emulation changes, then the MSR list available to the guest might change also. The list is also dependant on CPUID (CPU templates) since some MSRs are not available if CPUID features are disabled. Lastly, this tests also checks for MSR values against the baseline. This helps validate that defaults have not changed due to emulation implementation changes in the kernel.

• [ ] This functionality can be added in rust-vmm.

License Acceptance

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

PR Checklist

[Author TODO: Meet these criteria.] [Reviewer TODO: Verify that these criteria are met. Request changes if not]

• [x] All commits in this PR are signed (git commit -s).
• [ ] The issue which led to this PR has a clear conclusion.
• [ ] This PR follows the solution outlined in the related issue.
• [x] The description of changes is clear and encompassing.
• [x] Any required documentation changes (code and docs) are included in this PR.
• [x] Any newly added unsafe code is properly documented.
• [x] Any API changes follow the Runbook for Firecracker API changes.
• [x] Any user-facing changes are mentioned in CHANGELOG.md.
• [x] All added/changed functionality is tested.

[alsrdn]

No blockers from my side. Other thoughts as a side note.

• It's a pity that parity across the 3 vendors will be tricky to achieve. Not sure what the tooling will be like.
• Specific notice to MSR lists that are defined specifically to the kernel version. Is there any way to flatten into a generic file? Otherwise upgrading to newer kernel versions becomes harder as we introduce more kernel version specific code/configuration. If there is a runbook for upgrading Kernels, it would be nice to add a note on how to generate these lists.

• What do you mean about parity across 3 vendors?
• I'm not sure why a flattened file containing all kernels would bring here. Not sure what you mean by generic?
• WRT how the baseline files are generated, I can add a comment in the test. They are generated with the msr_reader.sh script on each kernel version.

[mattschlebusch]

Based on our offline conversation, a number of these changes I had questions for are either required or unavoidable.

I'm not sure why a flattened file containing all kernels would bring here. Not sure what you mean by generic?

My main thought here is just to minimize the work that would be needed whenever upgrading the supported kernel version from say 4.14 to 6.0.

What do you mean about parity across 3 vendors?

Being able to run these(or similar) tests across Intel, AMD and ARM, across supported Kernel versions could have considerable maintenance. Given current understanding and requirements, this problem is not in scope for this PR though.

[alsrdn]

Based on our offline conversation, a number of these changes I had questions for are either required or unavoidable.

I'm not sure why a flattened file containing all kernels would bring here. Not sure what you mean by generic?

My main thought here is just to minimize the work that would be needed whenever upgrading the supported kernel version from say 4.14 to 6.0.

What do you mean about parity across 3 vendors?

Being able to run these(or similar) tests across Intel, AMD and ARM, across supported Kernel versions could have considerable maintenance. Given current understanding and requirements, this problem is not in scope for this PR though.

Unfortunately we depend on KVM emulation for MSRs and we would need to track it across kernel version. I don't think we'll going to test across Intel and AMD unless we explicitly want to support snapshotting across them. For ARM we need a separate solution since it doesn't follow the x86 model.