Re: [PATCH v14 8/9] KVM: x86: virtualize cpuid faulting

From: Jim Mattson
Date: Fri Jul 27 2018 - 13:15:37 EST

On Wed, Feb 8, 2017 at 12:09 AM, Kyle Huey <me@xxxxxxxxxxxx> wrote:
> Hardware support for faulting on the cpuid instruction is not required to
> emulate it, because cpuid triggers a VM exit anyways. KVM handles the relevant
> cpuid-induced VM exit checks the cpuid faulting state and the CPL.
> kvm_require_cpl is even kind enough to inject the GP fault for us.
> Signed-off-by: Kyle Huey <khuey@xxxxxxxxxxxx>
> Reviewed-by: David Matlack <dmatlack@xxxxxxxxxx>

I have a couple of concerns about portions of this patch:

1) There are some backward compatibility issues:
A) Suppose we have an old userspace that doesn't know it needs to
zero MSR_PLATFORM_INFO to preserve existing behavior (to the extent
possible). If a VM starts on a new kernel it could set the bit in
MSR_MISC_FEATURES_ENABLES that enables CPUID faulting. On
live-migration to an old kernel, that bit would be lost.
B) With either an old userspace or a new userspace, as a VM migrates
between old and new kernels, the behavior of RDMSR with ECX set to
depending on which kernel the VM is currently running on.
Ideally, I think this new functionality should be guarded by a KVM
capability that has to be enabled from userspace.

2) This doesn't really play well with volume 3 of the SDM, section
18.7.3, where Intel instructs developers to use
MSR_PLATFORM_INFO[15:8] to determine the TSC frequency for a variety
of microarchitectures. When reads of this MSR raised #GP, it was
pretty clear that one couldn't get the TSC frequency that way, but I
don't think many consumers would specifically check for a 0 in that
field when the RDMSR succeeds. If a guest hypervisor used that value
in the computation of the TSC scaling factor for a VMCS12, for
example, it might be surprised to get a #DE.