More Advanced KVM Capability Related Checks

[alexandruag]

While trying to determine which KVM caps to check for to resolve #278, I stumbled upon some rather arcane (for now at least :-s) passages in the KVM API documentation, which appear to be worth checking out. Also, the logic used to solve #278 had some byproducts (information about max_vcpus supported by KVM) which are not yet used in further validation code. That being said, solving this issue requires the following:

• [ ] Do something with the max_vcpus information.
• [ ] Do something about this passage from the KVM API docs (or decide that it's not interesting):

If KVM_X2APIC_API_USE_32BIT_IDS feature of KVM_CAP_X2APIC_API is enabled, then the format of APIC_ID register depends on the APIC mode (reported by MSR_IA32_APICBASE) of its VCPU. x2APIC stores APIC ID in the APIC_ID register (bytes 32-35). xAPIC only allows an 8-bit APIC ID which is stored in bits 31-24 of the APIC register, or equivalently in byte 35 of struct kvm_lapic_state's regs field. KVM_GET_LAPIC must then be called after MSR_IA32_APICBASE has been set with KVM_SET_MSR. If KVM_X2APIC_API_USE_32BIT_IDS feature is disabled, struct kvm_lapic_state always uses xAPIC format.

• [ ] Also do something about this other passage:

Note: if kvm indicates supports MCE (KVM_CAP_MCE), then the MCE bank MSRs are not returned in the MSR list, as different vcpus can have a different number of banks, as set via the KVM_X86_SETUP_MCE ioctl.

[acatangiu]

We need to get input from @filipposironi on this.

[andreeaflorescu]

This might be related to #597

[kalyazin]

We took a look at this internally and decided that there was no pending action, mainly because the issue had been open for 6 years and we were not aware of related issues.