[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 03/10] x86: Add Intel Processor Trace support for cpuid
>>> On 30.05.18 at 15:27, <luwei.kang@xxxxxxxxx> wrote: > @@ -759,12 +760,19 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t > domid, > continue; > } > > + if ( input[0] == 0x14 ) > + { > + input[1]++; > + if ( input[1] == 1 ) > + continue; > + } Together with what's there and what iirc Andrew's series puts here, this should become a switch() imo. > @@ -583,7 +584,19 @@ void recalculate_cpuid_policy(struct domain *d) > __clear_bit(X86_FEATURE_VMX, max_fs); > __clear_bit(X86_FEATURE_SVM, max_fs); > } > + > + /* > + * Hide Intel Processor trace feature when hardware not support > + * PT-VMX or ipt option is off. > + */ > + if ( ipt_mode == IPT_MODE_OFF ) > + { > + __clear_bit(X86_FEATURE_IPT, max_fs); > + zero_leaves(p->ipt.raw, 0, ARRAY_SIZE(p->ipt.raw) - 1); > + } The clearing of bits in max_fs further up is needed here because this varies depending on domain config. You, otoh, put a conditional here which is not going to change post boot. This instead belongs into calculate_hvm_max_policy() I believe. > @@ -101,6 +102,10 @@ static int update_domain_cpuid_info(struct domain *d, > p->feat.raw[ctl->input[1]] = leaf; > break; > > + case IPT_CPUID: > + p->ipt.raw[ctl->input[1]] = leaf; > + break; This lacks a bounds check of ctl->input[1] (in the earlier switch()). > --- a/xen/include/asm-x86/cpufeature.h > +++ b/xen/include/asm-x86/cpufeature.h > @@ -102,6 +102,7 @@ > #define cpu_has_mpx boot_cpu_has(X86_FEATURE_MPX) > #define cpu_has_rdseed boot_cpu_has(X86_FEATURE_RDSEED) > #define cpu_has_smap boot_cpu_has(X86_FEATURE_SMAP) > +#define cpu_has_ipt boot_cpu_has(X86_FEATURE_IPT) This definition is unused. > --- a/xen/include/asm-x86/cpuid.h > +++ b/xen/include/asm-x86/cpuid.h > @@ -58,10 +58,11 @@ DECLARE_PER_CPU(struct cpuidmasks, cpuidmasks); > /* Default masking MSR values, calculated at boot. */ > extern struct cpuidmasks cpuidmask_defaults; > > -#define CPUID_GUEST_NR_BASIC (0xdu + 1) > +#define CPUID_GUEST_NR_BASIC (0x14u + 1) Is there anything to convince me that the intermediate leaves don't need any further handling added anywhere? Same question btw for the libxc side bumping of DEF_MAX_BASE. > @@ -166,6 +167,15 @@ struct cpuid_policy > } comp[CPUID_GUEST_NR_XSTATE]; > } xstate; > > + /* Structured feature leaf: 0x00000014[xx] */ > + union { > + struct cpuid_leaf raw[CPUID_GUEST_NR_IPT]; > + struct { > + /* Subleaf 0. */ > + uint32_t max_subleaf; > + }; > + } ipt; In particular this looks to be placed earlier than it should be (in other words I'm getting the impression that you failed to insert some padding for the skipped leaves). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |