WIP: Make CPU profiles MSR aware

[olivereanderson]

This PR adds functionality to modify and restrict MSRs based on CPU profiles.

Hints for reviewers: Please read the following description below in its entirety and then review this commit for commit.

Description

This PR continues the work merged in #62. If you do not recall the details from that PR I suggest reading the PR description again before continuing.

MSR-based features

Most CPU features can indeed be probed through CPUID, but there are a few that instead require MSR inspection.
We follow KVM and name these MSR-based features (See KVM_GET_MSR_FEATURE_INDEX_LIST).

Up to this point in time a similar Time-of-check-to-time-of-use bug as described in the context of CPUID in #62 can occur in the context of MSRs. Indeed suppose for example that a guest checks IA32_VMX_VMCS_ENUM to find the highest index value used for any VMCS encoding and then a live migration to a machine with a lower value occurs.
Even though KVM will (presumably) catch this potential error when attempting to set MSRs on the migration destination, it still means that live migration can never take place between these machines.

Hence in order to force a higher level of compatibility we take advantage of the fact that KVM can lie to guests about MSRs values in an analogous manner to the CPUID case.

We thus extend the CPU profile generation tool to also record necessary adjustments to the MSR-based feature values, using profile policies similar to those we previously introduced in the CPUID context.

MSR filters

At this point in time there are less than 40 MSR-based features that KVM will return when calling KVM_GET_MSR_FEATURE_INDEX_LIST on any given Intel CPU, but this is only a small fraction of the number of MSRs that are actually supported by the hardware and/or hypervisor.

While many MSRs are described as only being accessible if certain CPUID bits/values are present, there are some that are available on all CPUs of introduced after a certain generation (without CPUID requirements), and even some MSRs that are only available on specific CPUs. The latter are referred to as non-architectural msrs. MSRs whose values (although possibly different) have the same definitions across processor generations are called architectural MSRS (prefixed with IA32).

To combat the problem of MSRs that may only be available on the source VM, but not on the destination VM,
we take advantage of KVM's KVM_X86_SET_MSR_FILTER which enables us to deny guests from accessing entire ranges of MSRs.

More precisely we record a subset of the architectural MSRs supported by the hardware and hypervisor into the CPU profile and set up a filter to deny any MSRs not listed there when the CPU profile is applied.

Note that it is possible to perform even more fine grained MSR filtering (only denying individual bits) with KVM_CAP_X86_USER_SPACE_MSR, but we don't think that is necessary in our case.

CPUID adjustments

Some of the commits here are related to CPUID profile policy adjustments because they turned out to be problematic when testing the CPU profiles after adding MSR adjustments.

Making the CPU profile generation tool future proof

The whole point of the CPU profile generation tool is to automate the process of creating CPU profiles for new CPUs. Since new CPU generations (or KVM versions) may introduce new architectural MSRs (possibly even MSR-based features) that we are not yet aware of, we make the CPU profile tool emit warnings whenever it encounters MSRs that it is not aware of.

In this way we get notified when it might be time to update the MSR definitions used by the CPU profile tool. In order to achieve this we have introduced somewhat long lists of MSRs that we know about at this point in time. They have no other purpose other than helping us keep the CPU profile generation tool up to date!

Note that bits within already existing MSRs might of course go from being reserved to defined in the future and we do not know of a good way to automatically detect that (especially since the reserved value is not necessarily 0 in every case).

[phip1611]

please change the PR target to the new gardenlinux branch

[olivereanderson]

closed in favour of #103