> > Allowing an unlimited number of MSRs to be specified via the VMX > > load/store MSR lists (e.g., vm-entry MSR load list) is bad for two > > reasons. First, a guest can specify an unreasonable number of MSRs, > > forcing KVM to process all of them in software. Second, the SDM bounds > > the number of MSRs allowed to be packed into the atomic switch MSR lists. > > Quoting the "Miscellaneous Data" section in the "VMX Capability > > Reporting Facility" appendix: > > > > "Bits 27:25 is used to compute the recommended maximum number of MSRs > > that should appear in the VM-exit MSR-store list, the VM-exit MSR-load > > list, or the VM-entry MSR-load list. Specifically, if the value bits > > 27:25 of IA32_VMX_MISC is N, then 512 * (N + 1) is the recommended > > maximum number of MSRs to be included in each list. If the limit is > > exceeded, undefined processor behavior may result (including a machine > > check during the VMX transition)." > > > > Thus, force a VM-entry to fail due to MSR loading when the MSR load > > list is too large. Similarly, trigger an abort during a VM exit that > > encounters an MSR load list or MSR store list that is too large. > > It's probably redundant/obvious, but I think it's worth calling out that > this is arbitrary KVM behavior, e.g. replace "Thus," with something like: > > Because KVM needs to protect itself and can't model "undefined processor > behavior", arbitrarily > > The changelog (and maybe a comment in the code) should also state that > the count is intentionally not pre-checked so as to maintain compability > with hardware inasmuch as possible. That's a subtlety that's likely to > lead to "cleanup" in the future :-) Done. > Code itself looks good, with the spurious vmx_control_msr() removed. Done.
