On Thu, Jun 28, 2018 at 09:03:29AM -0700, Jim Mattson wrote: > On Thu, Jun 28, 2018 at 7:28 AM, Sean Christopherson > <sean.j.christopherson@xxxxxxxxx> wrote: > > > Back to my question, what is the motivation for this change? > > The motivation was consistent behavior between software emulation and > hardware behavior, since they could potentially be mixed in the > execution of the same VM (particularly once live migration gets > checked in, and the VM migrates between pre- and post- Haswell > systems). > > > Dropping the AR byte reserved bits unconditionally makes KVM consistent with > > Haswell but inconsistent with respect to prior CPUs since this code > > path also affects non-shadowed VMWRITE. > > True, but on older CPUs, VMWRITE is only possible through software > emulation, so there isn't any need to be consistent with hardware. > This change does introduce an inconsistency with older versions of > kvm, but since live migration support for nested VMX isn't checked in > yet, that shouldn't be a problem. Gotcha. I think it's worth updating the comment and/or commit message to explain the intended behavior in depth, otherwise people like me might think we're arbitrarily choosing to emulate Haswell+. E.g.: /* * Some Intel CPUs drop the reserved bits of the AR byte * fields on VMWRITE, which can lead to divergent behavior * after migrating a VM. E.g. a nested VMRESUME might * unexpectedly fail after migrating from hardware that * drops the bits to hardware that preserves the bits and * thus performs the reserved bits consistency check. * Explicitly clear the reserved bits to ensure consistent * KVM behavior regardless of the underlying hardware. */
