[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALMp9eR_KbgNWfpXJr+FzP2e68isK3RsXwN1QgH72ni8VHwzfA@mail.gmail.com>
Date: Tue, 29 Jan 2019 10:01:15 -0800
From: Jim Mattson <jmattson@...gle.com>
To: Yang Weijiang <weijiang.yang@...el.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
Sean Christopherson <sean.j.christopherson@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
kvm list <kvm@...r.kernel.org>,
"Michael S. Tsirkin" <mst@...hat.com>, yu-cheng.yu@...el.com,
yi.z.zhang@...el.com, hjl.tools@...il.com,
Zhang Yi Z <yi.z.zhang@...ux.intel.com>
Subject: Re: [PATCH v2 1/7] KVM:VMX: Define CET VMCS fields and bits
On Tue, Jan 29, 2019 at 9:47 AM Jim Mattson <jmattson@...gle.com> wrote:
>
> On Wed, Jan 23, 2019 at 6:06 AM Yang Weijiang <weijiang.yang@...el.com> wrote:
> > Note: Although these VMCS fields are 64-bit, they don't have high fields.
>
> This statement directly contradicts the SDM, volume 3, appendix B.2:
>
> "A value of 1 in bits 14:13 of an encoding indicates a 64-bit field.
> There are 64-bit fields only for controls and for guest state. As
> noted in Section 24.11.2, every 64-bit field has two encodings, which
> differ on bit 0, the access type. Thus, each such field has an even
> encoding for full access and an odd encoding for high access."
Ah! They're not actually 64-bit fields. If you look at the encodings
(0x68XX and 0x6cxx), they're natural-width fields! Natural-width
fields don't have a high component.
Powered by blists - more mailing lists