From: Eduardo Habkost <ehabkost@redhat.com>
To: Luwei Kang <luwei.kang@intel.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, mtosatti@redhat.com,
Chao Peng <chao.p.peng@linux.intel.com>,
pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCH v4 1/2] i386: Add Intel Processor Trace feature support
Date: Fri, 9 Mar 2018 16:10:48 -0300 [thread overview]
Message-ID: <20180309191048.GA28578@localhost.localdomain> (raw)
In-Reply-To: <1520182116-16485-1-git-send-email-luwei.kang@intel.com>
On Mon, Mar 05, 2018 at 12:48:35AM +0800, Luwei Kang wrote:
> From: Chao Peng <chao.p.peng@linux.intel.com>
>
> 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 <chao.p.peng@linux.intel.com>
> Signed-off-by: Luwei Kang <luwei.kang@intel.com>
> ---
> From V3:
> - fix some typo;
> - add some comments and safty check.
>
> ---
> target/i386/cpu.c | 78 +++++++++++++++++++++++++++++++++++++++++++++++++++++--
> target/i386/cpu.h | 1 +
> target/i386/kvm.c | 23 ++++++++++++++++
> 3 files changed, 100 insertions(+), 2 deletions(-)
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index b5e431e..24e1693 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -173,7 +173,32 @@
> #define L2_ITLB_4K_ASSOC 4
> #define L2_ITLB_4K_ENTRIES 512
>
> -
> +/* CPUID Leaf 0x14 constants: */
> +#define INTEL_PT_MAX_SUBLEAF 0x1
> +/*
> + * bit[00]: IA32_RTIT_CTL.CR3 filter can be set to 1 and IA32_RTIT_CR3_MATCH
> + * MSR can be accessed;
> + * bit[01]: Support Configurable PSB and Cycle-Accurate Mode;
> + * bit[02]: Support IP Filtering, TraceStop filtering, and preservation
> + * of Intel PT MSRs across warm reset;
> + * bit[03]: Support MTC timing packet and suppression of COFI-based packets;
> + */
> +#define INTEL_PT_MINIMAL_EBX 0xf
Thanks! I didn't expect a detailed description of each bit. I
thought that just adding macros for each bit instead of
hardcoding 0xf would be enough.
But after reading the docs, I understand it could be difficult to
choose a macro name for something like "support of IP Filtering,
TraceStop filtering, and preservation of Intel PT MSRs across
warm reset", so this description looks like the best we can do.
:)
I only see a problem below:
> +/*
> + * bit[00]: Tracing can be enabled with IA32_RTIT_CTL.ToPA = 1 and
> + * IA32_RTIT_OUTPUT_BASE and IA32_RTIT_OUTPUT_MASK_PTRS MSRs can be
> + * accessed;
> + * bit[01]: ToPA tables can hold any number of output entries, up to the
> + * maximum allowed by the MaskOrTableOffset field of
> + * IA32_RTIT_OUTPUT_MASK_PTRS;
> + * bit[02]: Support Single-Range Output scheme;
> + */
> +#define INTEL_PT_MINIMAL_ECX 0x7
> +#define INTEL_PT_ADDR_RANGES_NUM 0x2 /* Number of configurable address ranges */
> +#define INTEL_PT_ADDR_RANGES_NUM_MASK 0x3
> +#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)
[...]
> @@ -4083,6 +4129,34 @@ static int x86_cpu_filter_features(X86CPU *cpu)
> }
> }
>
> + if ((env->features[FEAT_7_0_EBX] & CPUID_7_0_EBX_INTEL_PT) &&
> + kvm_enabled()) {
> + 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 ||
> + ((ebx_0 & INTEL_PT_MINIMAL_EBX) != INTEL_PT_MINIMAL_EBX) ||
> + ((ecx_0 & INTEL_PT_MINIMAL_ECX) != INTEL_PT_MINIMAL_ECX) ||
> + ((eax_1 & INTEL_PT_MTC_BITMAP) != INTEL_PT_MTC_BITMAP) ||
> + ((eax_1 & INTEL_PT_ADDR_RANGES_NUM_MASK) <
> + INTEL_PT_ADDR_RANGES_NUM) ||
> + ((ebx_1 & (INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP)) !=
> + (INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP))) {
I still don't see a check to ensure the host has bit 31 on ecx_0
set to 0, as I mentioned when reviewing v3.
The rest of the patch looks good.
> + /*
> + * 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.
> + */
> + 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;
> + rv = 1;
> + }
> + }
> +
> return rv;
> }
>
[...]
--
Eduardo
next prev parent reply other threads:[~2018-03-09 19:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-04 16:48 [Qemu-devel] [PATCH v4 1/2] i386: Add Intel Processor Trace feature support Luwei Kang
2018-03-04 16:48 ` [Qemu-devel] [PATCH v4 2/2] i386: Add support to get/set/migrate Intel Processor Trace feature Luwei Kang
2019-10-12 3:14 ` Eduardo Habkost
2019-10-15 12:51 ` Kang, Luwei
2019-10-15 13:29 ` Eduardo Habkost
2019-10-21 6:02 ` Kang, Luwei
2019-10-22 21:44 ` Eduardo Habkost
2019-10-24 11:22 ` Kang, Luwei
2019-10-24 13:24 ` Eduardo Habkost
2019-10-24 13:36 ` Kang, Luwei
2019-10-24 14:15 ` Eduardo Habkost
2018-03-09 19:10 ` Eduardo Habkost [this message]
2018-03-12 9:07 ` [Qemu-devel] [PATCH v4 1/2] i386: Add Intel Processor Trace feature support Kang, Luwei
2018-03-12 16:45 ` Eduardo Habkost
2018-03-13 11:16 ` Kang, Luwei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180309191048.GA28578@localhost.localdomain \
--to=ehabkost@redhat.com \
--cc=chao.p.peng@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=luwei.kang@intel.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).