[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 1/2] i386: Add Intel Processor Trace feature
|
From: |
Kang, Luwei |
|
Subject: |
Re: [Qemu-devel] [PATCH v3 1/2] i386: Add Intel Processor Trace feature support |
|
Date: |
Thu, 8 Feb 2018 01:24:46 +0000 |
> On Wed, Jan 31, 2018 at 11:57:45PM +0800, Luwei Kang wrote:
> > From: Chao Peng <address@hidden>
> >
> > Expose Intel Processor Trace feature to guest.
> >
> > To make Intel PT live migration safe and get same CPUID information
> > with same CPU model on diffrent host. CPUID[14] is constant in this
> > patch. Intel PT use EPT is first supported in IceLake, the CPUID[14]
> > get on this machine as default value. Intel PT would be disabled If
> > any machine don't support this minial feature list.
> >
> > Signed-off-by: Chao Peng <address@hidden>
> > Signed-off-by: Luwei Kang <address@hidden>
> > ---
> > target/i386/cpu.c | 53
> > +++++++++++++++++++++++++++++++++++++++++++++++++++--
> > target/i386/cpu.h | 1 +
> > target/i386/kvm.c | 23 +++++++++++++++++++++++
> > 3 files changed, 75 insertions(+), 2 deletions(-)
> >
> > diff --git a/target/i386/cpu.c b/target/i386/cpu.c index
> > a49d222..aaa427a 100644
> > --- a/target/i386/cpu.c
> > +++ b/target/i386/cpu.c
> > @@ -172,7 +172,14 @@
> > #define L2_ITLB_4K_ASSOC 4
> > #define L2_ITLB_4K_ENTRIES 512
> >
> > -
> > +/* CPUID Leaf 0x14 constants: */
> > +#define INTLE_PT_MAX_SUBLEAF 0x1
>
> Typo.
>
> > +#define INTEL_PT_MINIMAL_EBX 0xf
> > +#define INTEL_PT_MINIMAL_ECX 0x7
>
> I suggest documenting what capabilities are included in
> INTEL_PT_MINIMAL_* here.
>
>
> > +#define INTLE_PT_ADDR_RANGES_NUM 0x2 /* Number of configurable
> > +address ranges */
>
> Typo.
>
> > +#define INTEL_PT_MTC_BITMAP (0x0249 << 16) /* Support ART(0,3,6,9) */
> > +#define INTEL_PT_CYCLE_BITMAP 0x1fff /* Support 0,2^(0~11) */
> > +#define INTEL_PT_PSB_BITMAP (0x003f << 16) /* Support
> > 2K,4K,8K,16K,32K,64K */
> >
> > static void x86_cpu_vendor_words2str(char *dst, uint32_t vendor1,
> > uint32_t vendor2, uint32_t
> > vendor3) @@ -427,7 +434,7 @@ static FeatureWordInfo
> > feature_word_info[FEATURE_WORDS] = {
> > NULL, NULL, "mpx", NULL,
> > "avx512f", "avx512dq", "rdseed", "adx",
> > "smap", "avx512ifma", "pcommit", "clflushopt",
> > - "clwb", NULL, "avx512pf", "avx512er",
> > + "clwb", "intel-pt", "avx512pf", "avx512er",
> > "avx512cd", "sha-ni", "avx512bw", "avx512vl",
> > },
> > .cpuid_eax = 7,
> > @@ -3452,6 +3459,27 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
> > uint32_t count,
> > }
> > break;
> > }
> > + case 0x14: {
> > + /* Intel Processor Trace Enumeration */
> > + *eax = 0;
> > + *ebx = 0;
> > + *ecx = 0;
> > + *edx = 0;
> > + if (!(env->features[FEAT_7_0_EBX] & CPUID_7_0_EBX_INTEL_PT) ||
> > + !kvm_enabled()) {
> > + break;
> > + }
> > +
> > + if (count == 0) {
> > + *eax = INTLE_PT_MAX_SUBLEAF;
> > + *ebx = INTEL_PT_MINIMAL_EBX;
> > + *ecx = INTEL_PT_MINIMAL_ECX;
> > + } else if (count == 1) {
> > + *eax = INTEL_PT_MTC_BITMAP | INTLE_PT_ADDR_RANGES_NUM;
> > + *ebx = INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP;
> > + }
> > + break;
> > + }
> > case 0x40000000:
> > /*
> > * CPUID code in kvm_arch_init_vcpu() ignores stuff @@
> > -4082,6 +4110,27 @@ static int x86_cpu_filter_features(X86CPU *cpu)
> > }
> > }
> >
> > + if (env->features[FEAT_7_0_EBX] & CPUID_7_0_EBX_INTEL_PT) {
>
> What if the accelerator is not KVM, but is reporting intel-pt as supported?
I have add this check in cpu_x86_cpuid() but I think we'd better add
kvm_enabled() check here as well.
What is your opinion?
>
> > + KVMState *s = CPU(cpu)->kvm_state;
> > + uint32_t eax_0 = kvm_arch_get_supported_cpuid(s, 0x14, 0, R_EAX);
> > + uint32_t ebx_0 = kvm_arch_get_supported_cpuid(s, 0x14, 0, R_EBX);
> > + uint32_t ecx_0 = kvm_arch_get_supported_cpuid(s, 0x14, 0, R_ECX);
> > + uint32_t eax_1 = kvm_arch_get_supported_cpuid(s, 0x14, 1, R_EAX);
> > + uint32_t ebx_1 = kvm_arch_get_supported_cpuid(s, 0x14, 1,
> > + R_EBX);
> > +
> > + if (!eax_0 ||
>
> OK.
>
> > + ((ebx_0 & INTEL_PT_MINIMAL_EBX) != INTEL_PT_MINIMAL_EBX)
> > + ||
>
> How do we know if KVM is going to emulate #GP properly when setting a bit
> that is supported by the host CPU but cleared on the
> guest CPUID? Do we care?
I think it need KVM make this check and Qemu don't need aware this.
For example, EBX[0].CR3_filter (IA32_RTIT_CTL.cr3 can't be set if 0) is support
by host but we mask off this bit in kvm guest. Qemu will set the CPUID to KVM
by ioctl KVM_SET_CPUID2. KVM will trap the behavior when KVM guest want to set
IA32_RTIT_CTL.cr3. If we find EBX[0].CR3_filter is not supported a #GP will be
emulated. This check will added in KVM patch set V5 and it still working in
progress.
>
> > + ((ecx_0 & INTEL_PT_MINIMAL_ECX) != INTEL_PT_MINIMAL_ECX)
> > + ||
>
> Same comment as above.
>
> Also: bit 31 must match the host, meaning we must reject a host where ecx_0 &
> (1 << 31) is set.
Get it, will add in next version.
>
>
> > + ((eax_1 & (INTLE_PT_ADDR_RANGES_NUM | INTEL_PT_MTC_BITMAP)) !=
> > + (INTLE_PT_ADDR_RANGES_NUM | INTEL_PT_MTC_BITMAP)) ||
>
> This will make the code accept hosts with 3 address ranges (0b011), but
> reject ones with 4 address ranges (0b100). This doesn't
> sound right to me.
I see, will fix it.
>
>
> > + ((ebx_1 & (INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP)) !=
> > + (INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP))) {
>
> How do we know if KVM is going to emulate #GP properly when setting an
> invalid CycThresh or PSBFreq value? Do we care?
It will check in KVM and will emulate a #GP if set an invalid value but I think
qemu can't aware this.
>From my point of view, I think qemu don't need to care or get this information.
>
>
> > + env->features[FEAT_7_0_EBX] &= ~CPUID_7_0_EBX_INTEL_PT;
> > + cpu->filtered_features[FEAT_7_0_EBX] |=
> > + CPUID_7_0_EBX_INTEL_PT;
>
> This matches what I have suggested. But I recommend adding a comment
> mentioning why we do this. Something like:
>
> /*
> * Processor Trace capabilities aren't configurable, so if the
> * host can't emulate the capabilities we report on
> * cpu_x86_cpuid(), intel-pt can't be enabled on the current host.
> */
Agree.
Thanks a lot for the code review.
Luwei Kang
>
>
> > + rv = 1;
> > + }
> > + }
> > +
> > return rv;
> > }
> >
> > diff --git a/target/i386/cpu.h b/target/i386/cpu.h index
> > f91e37d..7facc8b 100644
> > --- a/target/i386/cpu.h
> > +++ b/target/i386/cpu.h
> > @@ -644,6 +644,7 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS];
> > #define CPUID_7_0_EBX_PCOMMIT (1U << 22) /* Persistent Commit */
> > #define CPUID_7_0_EBX_CLFLUSHOPT (1U << 23) /* Flush a Cache Line Optimized
> > */
> > #define CPUID_7_0_EBX_CLWB (1U << 24) /* Cache Line Write Back */
> > +#define CPUID_7_0_EBX_INTEL_PT (1U << 25) /* Intel Processor Trace */
> > #define CPUID_7_0_EBX_AVX512PF (1U << 26) /* AVX-512 Prefetch */
> > #define CPUID_7_0_EBX_AVX512ER (1U << 27) /* AVX-512 Exponential and
> > Reciprocal */ #define CPUID_7_0_EBX_AVX512CD (1U << 28) /* AVX-512
> > Conflict Detection */ diff --git a/target/i386/kvm.c
> > b/target/i386/kvm.c index ad4b159..f9f4cd1 100644
> > --- a/target/i386/kvm.c
> > +++ b/target/i386/kvm.c
> > @@ -865,6 +865,29 @@ int kvm_arch_init_vcpu(CPUState *cs)
> > c = &cpuid_data.entries[cpuid_i++];
> > }
> > break;
> > + case 0x14: {
> > + uint32_t times;
> > +
> > + c->function = i;
> > + c->index = 0;
> > + c->flags = KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
> > + cpu_x86_cpuid(env, i, 0, &c->eax, &c->ebx, &c->ecx, &c->edx);
> > + times = c->eax;
> > +
> > + for (j = 1; j <= times; ++j) {
> > + if (cpuid_i == KVM_MAX_CPUID_ENTRIES) {
> > + fprintf(stderr, "cpuid_data is full, no space for "
> > + "cpuid(eax:0x14,ecx:0x%x)\n", j);
> > + abort();
> > + }
> > + c = &cpuid_data.entries[cpuid_i++];
> > + c->function = i;
> > + c->index = j;
> > + c->flags = KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
> > + cpu_x86_cpuid(env, i, j, &c->eax, &c->ebx, &c->ecx,
> > &c->edx);
> > + }
> > + break;
> > + }
> > default:
> > c->function = i;
> > c->flags = 0;
> > --
> > 1.8.3.1
> >
> >
>
> --
> Eduardo