CPUID (3/3): CPUID template expansion

[JonathanWoollett-Light]

#3105 must be merged first

Reason for This PR

Many properties CPUID are not considered when saving and restoring snapshots, this leads to potential instability.

Description of Changes

Reworked the CPUID to support extensive CPU templates, simplifying the existing flow and adding accessor functions and types.

The CPUID templates are under src/cpuid-templates/, these have been generated from booting a microVM using Firecracker main with the respective template then reading CPUID from within the microVM.

Expanding CPUID to include accessors for most of the Intel specification and some of the AMD specification.

The crate has split into 3 portions, general (cpuid/), Intel specific (cpuid/intel) and AMD specific (cpuid/amd).

Within these:

• indexing.rs contains the leaf index implementations
• leaves.rs contains the leaf definitions,
• mod.rs contains the outer structure (Cpuid, IntelCpuid and AmdCpuid respectively).
• normalize contains the normalize functions which replace filter_cpuid and the CPUID transformer logic.
• registers.rs contains the register definitions for leaves.

At the root common.rs retains some of the old functionality that is still used.

CpuidTrait::apply_brand_string, IntelCpuid::default_brand_string() and AmdCpuid::DEFAULT_BRAND_STRING replace cpuid/src/brand_string.rs.

Adjustments to testing:

• test_coverage values have been significantly reduced.
• test_coverage timeout has been increased to 600 as it was consistently timing out on the m6gd instance in CI.
• test_brand_string has been simplified.
• test_api_machine_config has had a message slightly changed.

Linting

This continues the pattern of linting as introduced in #3105.

Code coverage

Code coverage is significantly reduced in large part due to the quantity of generated code for CPUID registers, this can be seen in the report (coverage-report-cpuid-latest.zip) as there ~1000 lines of uncovered generated code under src/cpuid/intel/registers.rs.

Generated doc tests being excluded from code coverage makes higher coverage difficult here (including doc tests in coverage is a nightly feature).

Future work

There are clear areas where future work would be useful:

• Propagating RawCpuid to rust-vmm.(to replace CpuId/FamWrapper) Renovating CpuId rust-vmm/kvm#295
• Future work could cover compatibility checking on the remaining unchecked Intel leaves and some compatibility checking on AMD. We only check the following leaves on Intel currently:
  • 0x00
  • 0x01: not EAX and partially EBX.
  • 0x05: not EDX.
  • 0x07
  • 0x0A: not EAX, EBX & EDX.
  • 0x0F: not EBX in sub-leaf 1.
  • 0x10: not sub-leavers 2 & 3, not EAX, EBX & ECX in sub-leaf 1.
  • 0x14: not sub-leaf 1.
  • 0x18, not sub-leaves >0, not ECX & EDX in sub-leaf 0.
  • 0x19
  • 0x1C: not EAX
  • 0x20: not EBX
  • 0x80000000
  • 0x80000001 not EAX.
  • 0x80000007
  • 0x80000008
• We do not define accessory structs for Intel leaves: 0xD and 0x1B future work could introduce these.
• Considering the areas where checking both MSRs and CPUID in parallel is required for correctness.
• src/cpuid/src/common.rs and src/cpuid/src/bit_helper.rs can be significantly reduced in size by removing unused functionality.

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

• 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.
• The description of changes is clear and encompassing.
• Any required documentation changes (code and docs) are included in this PR.
• Any newly added unsafe code is properly documented.
• Any API changes follow the Runbook for Firecracker API changes.
• Any user-facing changes are mentioned in CHANGELOG.md.
• All added/changed functionality is tested.

[alsrdn]

Really cool work done here!
I've done a pass of this PR but I have not gone into the implementation too deeply since it's a draft. I've added some comments related to how the new crates are integrated in Firecracker and I'll take another pass at it once we settle the Firecracker integration side.

I think this PR can be split into at least 3 PRs each with multiple commits to make it more manageable to review:

• One PR that refactors error handling and propagation within Firecracker. This can be even opened agains the main branch since its not too coupled to the CPUID crate.
• One PR adding the bit-fields-macros and bit-fields crates.
• One PR for the new implementation of the cpuid crate and changes to Firecracker to make it work.

Each one of these PRs can have multiple commits that can be logically split.

[JonathanWoollett-Light]

I think this PR can be split into at least 3 PRs each with multiple commits to make it more manageable to review:

• One PR that refactors error handling and propagation within Firecracker. This can be even opened agains the main branch since its not too coupled to the CPUID crate.
• One PR adding the bit-fields-macros and bit-fields crates.
• One PR for the new implementation of the cpuid crate and changes to Firecracker to make it work.

These make sense, but I think the second one might be a bit odd. Given it would be a PR adding libraries that are not being used. It would require some extra description noting it is linked to other PRs.