On Wed, Jun 27, 2018 at 03:19:09PM -0700, Jim Mattson wrote: > On Wed, Jun 27, 2018 at 3:13 PM, Liran Alon <liran.alon@xxxxxxxxxx> wrote: > > > > On 28/06/18 00:41, Sean Christopherson wrote: > >> > >> On Sat, Jun 23, 2018 at 02:35:22AM +0300, Liran Alon wrote: > >>> > >>> From: Jim Mattson <jmattson@xxxxxxxxxx> > >>> > >>> Haswell and later hardware masks off the irrelevant bits if the guest > >>> access rights fields on vmwrite, storing only the 13 relevant > >>> bits. This masking isn't documented anywhere. When using VMCS > >>> shadowing for these fields, these fields will be masked when written > >>> to the shadow vmcs12. For consistency, mask these fields when the > >>> vmwrite is handled in software. > >> > >> Is there software that actively relies on this hardware behavior > >> or is this more of a cosmetic issue, e.g. it causes failures in a > >> fuzzer or memory checker of some form? > >> > >> Not that it really matters, but I think it'd be more correct to > >> model this behavior in the VMREAD path. > >> > > > > > > Because you think that CPU writes full content to access right field in VMCS > > memory > > but VMREAD is the one that actually mask the content? > > VMWRITE definitely does not write the full content to memory. The VMCS > format for Haswell and later packs the access rights fields. (You can > verify this by doing a VMCLEAR.) My thought process regarding VMREAD vs VMWRITE was that the behavior would only be architecturally visible on VMREAD, but I forgot that the Haswell behavior is also visible at VMEnter since dropping the reserved bits makes it impossible to generate a consistency check due to said bits being non-zero. Back to my question, what is the motivation for this change? If this patch was prompted by a test failure then I think it makes more sense to "fix" the test, i.e. eliminate the AR byte test case. 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. As for documentation, I'll submit an SDM bug to try and get a blurb added stating that the reserved bits may be dropped on some CPUs.
