From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
To: Luwei Kang <luwei.kang@intel.com>
Cc: kvm@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com,
hpa@zytor.com, x86@kernel.org, chao.p.peng@linux.intel.com,
thomas.lendacky@amd.com, bp@suse.de, Kan.liang@intel.com,
Janakarajan.Natarajan@amd.com, dwmw@amazon.co.uk,
linux-kernel@vger.kernel.org, alexander.shishkin@linux.intel.com,
peterz@infradead.org, mathieu.poirier@linaro.org,
kstewart@linuxfoundation.org, gregkh@linuxfoundation.org,
pbonzini@redhat.com, rkrcmar@redhat.com, david@redhat.com,
bsd@redhat.com, yu.c.zhang@linux.intel.com, joro@8bytes.org
Subject: Re: [PATCH v9 09/12] KVM: x86: Introduce a function to initialize the PT configuration
Date: Thu, 7 Jun 2018 16:56:48 +0300 [thread overview]
Message-ID: <20180607135648.mkciyfrd2wgvdxze@um.fi.intel.com> (raw)
In-Reply-To: <1526964735-16566-10-git-send-email-luwei.kang@intel.com>
On Tue, May 22, 2018 at 12:52:12PM +0800, Luwei Kang wrote:
> Initialize the Intel PT configuration when cpuid update.
Is it the CPUID configuration? Is it the MSR configuration? Is it both?
Kind of looks like both. Not sure what is the cpuid update, though.
> Include cpuid inforamtion, rtit_ctl bit mask and the number of
> address ranges.
>
> Signed-off-by: Luwei Kang <luwei.kang@intel.com>
> ---
> arch/x86/kvm/vmx.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 70 insertions(+)
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 11fb90a..952ddf4 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -10411,6 +10411,72 @@ static void nested_vmx_cr_fixed1_bits_update(struct kvm_vcpu *vcpu)
> #undef cr4_fixed1_update
> }
>
> +static void update_intel_pt_cfg(struct kvm_vcpu *vcpu)
> +{
> + struct vcpu_vmx *vmx = to_vmx(vcpu);
> + struct kvm_cpuid_entry2 *best = NULL;
> + int i;
> +
> + for (i = 0; i < PT_CPUID_LEAVES; i++) {
> + best = kvm_find_cpuid_entry(vcpu, 0x14, i);
> + if (!best)
> + return;
> + vmx->pt_desc.caps[CPUID_EAX + i*PT_CPUID_REGS_NUM] = best->eax;
> + vmx->pt_desc.caps[CPUID_EBX + i*PT_CPUID_REGS_NUM] = best->ebx;
> + vmx->pt_desc.caps[CPUID_ECX + i*PT_CPUID_REGS_NUM] = best->ecx;
> + vmx->pt_desc.caps[CPUID_EDX + i*PT_CPUID_REGS_NUM] = best->edx;
> + }
> +
> + /* Get the number of configurable Address Ranges for filtering */
> + vmx->pt_desc.addr_range = pt_cap_decode(vmx->pt_desc.caps,
> + PT_CAP_num_address_ranges);
> +
> + /* Initialize and clear the no dependency bits */
> + vmx->pt_desc.ctl_bitmask = ~0ULL;
This looks redundant, doesn't it?
> + vmx->pt_desc.ctl_bitmask = ~(RTIT_CTL_TRACEEN | RTIT_CTL_OS |
> + RTIT_CTL_USR | RTIT_CTL_TSC_EN | RTIT_CTL_DISRETC);
> +
> + /* If CPUID.(EAX=14H,ECX=0):EBX[0]=1 CR3Filter can be set */
This comment makes it less clear than it would have been otherwise.
> + if (pt_cap_decode(vmx->pt_desc.caps, PT_CAP_cr3_filtering))
> + vmx->pt_desc.ctl_bitmask &= ~RTIT_CTL_CR3EN;
> +
> + /*
> + * If CPUID.(EAX=14H,ECX=0):EBX[1]=1 CYCEn, CycThresh and
> + * PSBFreq can be set
> + */
> + if (pt_cap_decode(vmx->pt_desc.caps, PT_CAP_psb_cyc))
> + vmx->pt_desc.ctl_bitmask &= ~(RTIT_CTL_CYCLEACC |
> + RTIT_CTL_CYC_THRESH | RTIT_CTL_PSB_FREQ);
> +
> + /*
> + * If CPUID.(EAX=14H,ECX=0):EBX[3]=1 MTCEn BranchEn and
> + * MTCFreq can be set
> + */
> + if (pt_cap_decode(vmx->pt_desc.caps, PT_CAP_mtc))
> + vmx->pt_desc.ctl_bitmask &= ~(RTIT_CTL_MTC_EN |
> + RTIT_CTL_BRANCH_EN | RTIT_CTL_MTC_RANGE);
> +
> + /* If CPUID.(EAX=14H,ECX=0):EBX[4]=1 FUPonPTW and PTWEn can be set */
> + if (pt_cap_decode(vmx->pt_desc.caps, PT_CAP_ptwrite))
> + vmx->pt_desc.ctl_bitmask &= ~(RTIT_CTL_FUP_ON_PTW |
> + RTIT_CTL_PTW_EN);
> +
> + /* If CPUID.(EAX=14H,ECX=0):EBX[5]=1 PwrEvEn can be set */
> + if (pt_cap_decode(vmx->pt_desc.caps, PT_CAP_power_event_trace))
> + vmx->pt_desc.ctl_bitmask &= ~RTIT_CTL_PWR_EVT_EN;
> +
> + /* If CPUID.(EAX=14H,ECX=0):ECX[0]=1 ToPA can be set */
> + if (pt_cap_decode(vmx->pt_desc.caps, PT_CAP_topa_output))
> + vmx->pt_desc.ctl_bitmask &= ~RTIT_CTL_TOPA;
If you want to be thorough, there's also PT_CAP_single_range_output, which
tells us if RTIT_CTL_TOPA can be *unset*. Otherwise it's required.
> + /* If CPUID.(EAX=14H,ECX=0):ECX[3]=1 FabircEn can be set */
> + if (pt_cap_decode(vmx->pt_desc.caps, PT_CAP_output_subsys))
> + vmx->pt_desc.ctl_bitmask &= ~RTIT_CTL_FABRIC_EN;
Are we sure we want to virtualize this and that it's safe?
> +
> + /* unmask address range configure area */
> + for (i = 0; i < vmx->pt_desc.addr_range; i++)
> + vmx->pt_desc.ctl_bitmask &= ~(0xf << (32 + i * 4));
So, the ctl_bitmask is all the bits that are not allowed?
Regards,
--
Alex
next prev parent reply other threads:[~2018-06-07 13:57 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-22 4:52 [PATCH v9 00/12] Intel Processor Trace virtualization enabling Luwei Kang
2018-05-22 4:52 ` [PATCH v9 01/12] perf/x86/intel/pt: Move Intel-PT MSRs bit definitions to a public header Luwei Kang
2018-06-07 6:50 ` Kang, Luwei
2018-06-07 11:21 ` Paolo Bonzini
2018-05-22 4:52 ` [PATCH v9 02/12] perf/x86/intel/pt: Change pt_cap_get() to a public function Luwei Kang
2018-05-22 4:52 ` [PATCH v9 03/12] perf/x86/intel/pt: Add new bit definitions for Intel PT MSRs Luwei Kang
2018-06-07 13:33 ` Alexander Shishkin
2018-06-08 14:26 ` Kang, Luwei
2018-05-22 4:52 ` [PATCH v9 04/12] perf/x86/intel/pt: add new capability for Intel PT Luwei Kang
2018-06-07 13:40 ` Alexander Shishkin
2018-06-07 13:51 ` Peter Zijlstra
2018-06-08 14:37 ` Kang, Luwei
2018-06-08 14:34 ` Kang, Luwei
2018-05-22 4:52 ` [PATCH v9 05/12] perf/x86/intel/pt: Introduce a new function to get capability of " Luwei Kang
2018-05-22 4:52 ` [PATCH v9 06/12] KVM: x86: Add Intel Processor Trace virtualization mode Luwei Kang
2018-06-07 13:26 ` Alexander Shishkin
2018-06-08 14:19 ` Kang, Luwei
2018-06-11 11:39 ` Paolo Bonzini
2018-05-22 4:52 ` [PATCH v9 07/12] KVM: x86: Add Intel Processor Trace cpuid emulation Luwei Kang
2018-05-22 4:52 ` [PATCH v9 08/12] KVM: x86: Add Intel Processor Trace context switch for each vcpu Luwei Kang
2018-05-22 4:52 ` [PATCH v9 09/12] KVM: x86: Introduce a function to initialize the PT configuration Luwei Kang
2018-06-07 13:56 ` Alexander Shishkin [this message]
2018-06-08 14:56 ` Kang, Luwei
2018-06-11 11:41 ` Paolo Bonzini
2018-06-12 1:30 ` Kang, Luwei
2018-05-22 4:52 ` [PATCH v9 10/12] KVM: x86: Implement Intel Processor Trace MSRs read/write emulation Luwei Kang
2018-06-07 14:12 ` Alexander Shishkin
2018-06-08 15:12 ` Kang, Luwei
2018-05-22 4:52 ` [PATCH v9 11/12] KVM: x86: Set intercept for Intel PT MSRs read/write Luwei Kang
2018-06-07 14:22 ` Alexander Shishkin
2018-06-08 15:16 ` Kang, Luwei
2018-05-22 4:52 ` [PATCH v9 12/12] KVM: x86: Disable Intel Processor Trace when VMXON in L1 guest Luwei Kang
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=20180607135648.mkciyfrd2wgvdxze@um.fi.intel.com \
--to=alexander.shishkin@linux.intel.com \
--cc=Janakarajan.Natarajan@amd.com \
--cc=Kan.liang@intel.com \
--cc=bp@suse.de \
--cc=bsd@redhat.com \
--cc=chao.p.peng@linux.intel.com \
--cc=david@redhat.com \
--cc=dwmw@amazon.co.uk \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=joro@8bytes.org \
--cc=kstewart@linuxfoundation.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luwei.kang@intel.com \
--cc=mathieu.poirier@linaro.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rkrcmar@redhat.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
--cc=yu.c.zhang@linux.intel.com \
/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
all inboxes | Powered by JetHome®