VMX MSR cleanup #56
Description
For the most part, we intercept every MSR write. We are explicit about saving/restoring the MSRs that aren't intercepted. However the intercepted MSRs run through an emulator, and some of those actually just let the MSR operation happen! In short, any use of emsr_ok is probably wrong. Some of them are MSRs the host isn't using, but if you have multiple VMs, they could be mucking with each others settings.
Similarly, we don't do anything for the IA32_PAT MSR. We might be telling the guest to not even try and use it (via .config or cpuid), since it's intercepted (by default) and not handled by the MSR vmexit codes. This means that the guest is probably using our host's PAT settings. That's OK if the settings are the same, and might save a little overhead on the vmexit/vmenter (assuming the vmcs load/save of IA32_PAT is just a write_msr under the hood, just like autoload).
The best thing for PAT is probably to turn off cpuid 0x01 edx[16], or whichever one tells the guest that the PAT MSR exists, and then set up our host PAT in the sane way: where it acts the way you'd expect if PTE_PCD or PTE_PWT are set. (I think I already did that). Also, we should check and see if our Linux guest is attempting to check IA32_PAT. If not, why not? If so, what is actually happening?