Re: [RFC PATCH v2 05/69] KVM: TDX: Add architectural definitions for structures and values

[Sean Christopherson]

On Wed, Aug 04, 2021, Erdem Aktas wrote:
> On Mon, Aug 2, 2021 at 6:25 AM Xiaoyao Li <xiaoyao.li@xxxxxxxxx> wrote:
> > > Is this information correct and is this included in the spec? I tried
> > > to find it but somehow I do not see it clearly defined.
> > >
> > >> +#define TDX1_NR_TDCX_PAGES             4
> > >> +#define TDX1_NR_TDVPX_PAGES            5
> > >> +
> > >> +#define TDX1_MAX_NR_CPUID_CONFIGS      6
> > > Why is this just 6? I am looking at the CPUID table in the spec and
> > > there are already more than 6 CPUID leaves there.
> >
> > This is the number of CPUID config reported by TDH.SYS.INFO. Current KVM
> > only reports 6 leaves.
> 
> I, personally, still think that it should be enumerated, rather than
> hardcoded. It is not clear to me why it is 6 and nothing in the spec
> says it will not change.

It's both hardcoded and enumerated.  KVM's hardcoded value is specifically the
maximum value expected for TDX-Module modules supporting the so called "1.0" spec.
It's certainly possible a spec change could bump the maximum, but KVM will refuse
to use a module with higher maximums until Linux/KVM is updated to play nice with
the new module.

Having hardcoded maximum allows for simpler and more efficient code, as loops and
arrays can be statically defined instead of having to pass around the enumerated
values.

And we'd want sanity checking anyways, e.g. if the TDX-module pulled a stupid and
reported that it needs 4000 TDCX pages.  This approach gives KVM documented values
to sanity check, e.g. instead of arbitrary magic numbers.

The downside of this approach is that KVM will need to be updated to play nice
with a new module if any of these maximums are raised.  But, IMO that's acceptable
because I can't imagine a scenario where anyone would want to load a TDX module
without first testing the daylights out of the specific kernel+TDX combination,
especially a TDX-module that by definition includes new features.

> > >> +#define TDX1_MAX_NR_CMRS               32
> > >> +#define TDX1_MAX_NR_TDMRS              64
> > >> +#define TDX1_MAX_NR_RSVD_AREAS         16
> > >> +#define TDX1_PAMT_ENTRY_SIZE           16
> > >> +#define TDX1_EXTENDMR_CHUNKSIZE                256
> > >
> > > I believe all of the defined variables above need to be enumerated
> > > with TDH.SYS.INFO.

And they are, though I believe the code for doing the actual SEAMCALL wasn't
posted in this series.  The output is sanity checked by tdx_hardware_enable():

+	tdx_caps.tdcs_nr_pages = tdsysinfo->tdcs_base_size / PAGE_SIZE;
+	if (tdx_caps.tdcs_nr_pages != TDX1_NR_TDCX_PAGES)
+		return -EIO;
+
+	tdx_caps.tdvpx_nr_pages = tdsysinfo->tdvps_base_size / PAGE_SIZE - 1;
+	if (tdx_caps.tdvpx_nr_pages != TDX1_NR_TDVPX_PAGES)
+		return -EIO;
+
+	tdx_caps.attrs_fixed0 = tdsysinfo->attributes_fixed0;
+	tdx_caps.attrs_fixed1 = tdsysinfo->attributes_fixed1;
+	tdx_caps.xfam_fixed0 =	tdsysinfo->xfam_fixed0;
+	tdx_caps.xfam_fixed1 = tdsysinfo->xfam_fixed1;
+
+	tdx_caps.nr_cpuid_configs = tdsysinfo->num_cpuid_config;
+	if (tdx_caps.nr_cpuid_configs > TDX1_MAX_NR_CPUID_CONFIGS)
+		return -EIO;
+