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.
