On Mon, Mar 25, 2019 at 07:39:09PM +0100, Borislav Petkov wrote:
> On Mon, Mar 25, 2019 at 11:21:33AM -0700, Sean Christopherson wrote:
> > Won't this prevent emulating an AMD guest on Intel hardware, e.g. due to
> > injecting #GPs during boot?
>
> I guess, but...
>
> > Keeping support in kvm_{get,set}_msr_common
> > doesn't preclude svm_{get,set}_msr() from having SVM-specific handling for
> > the MSR.
>
> ... is kvm_{get,set}_msr_common() supposed to cover for all those
> overlapping MSRs between AMD and Intel? svm_{get,set}_msr() have a lot
> more AMD-specific MSRs just like vmx_{get,set}_msr() respectively for
> Intel.
>
> Which would mean that if you really want to support those cross-vendor
> emulations, you don't need the svm* and vmx* MSR accessors... or am I
> missing something?
Generally speaking, the goal is to support cross-vendor VMs without having
to modify the guest kernel, i.e. exact emulation is out of scope. This
means "emulating" cross-vendor MSRs that the guest expects to exist to the
point where the guest won't explode, e.g. in the case of MSR_K7_HWCR, Linux
expects the MSR to exist on all AMD platforms and AFAICT will die during
boot if it doesn't.
The rule of thumb for "what MSRs can a guest reasonably expect to exist"
is fluid. The most clear cut cases are when support is explicitly
enumerated via some feature bit and KVM reports support for said feature
to userspace, e.g. if userspace advertises a feature (to the guest) that
KVM doesn't support, then it's a userspace bug.
But for MSRs like MSR_K7_HWCR and MSR_F10H_DECFG where their existence is
implicit, whoever came first often wins. For example, MSR_K7_HWCR existed
long before KVM and guest kernels expect it to exist on all AMD CPUs, so
KVM emulates it unconditionally. Whereas MSR_F10H_DECFG was recently
added and obviously not emulated on existing hypervisors, so the kernel
has to assume the MSR might not exist when running under a hypervisor,
which means KVM doesn't need to pretend the MSR uncondtionally exists.
