lkml.org 
[lkml]   [2019]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 1/7] KVM:VMX: Define CET VMCS fields and bits
On Tue, Jan 29, 2019 at 10:27:50AM -0800, Sean Christopherson wrote:
> On Tue, Jan 29, 2019 at 10:01:15AM -0800, Jim Mattson wrote:
> > On Tue, Jan 29, 2019 at 9:47 AM Jim Mattson <jmattson@google.com> wrote:
> > >
> > > On Wed, Jan 23, 2019 at 6:06 AM Yang Weijiang <weijiang.yang@intel.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.
>
> They're indeed natural width (I actually looked at the spec this time).
>
> The "_FULL" postfix on VMX_HOST_IA32_INTERRUPT_SSP_TABLE_ADDR_FULL and
> VMX_HOST_SSP_FULL is confusing as it generally only shows up on 64-bit
> fields. I'll see if we can get the fields renamed to drop "_FULL". I
> suggest we preemptively do the same for KVM.
Thank you for making it clear! I should have modified the annotation
correctly. I'll add a note for this in next version.

\
 
 \ /
  Last update: 2019-01-30 02:41    [W:0.077 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site