All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Michał Leszczyński" <michal.leszczynski@cert.pl>,
	"Roger Pau Monné" <roger.pau@citrix.com>, "Wei Liu" <wl@xen.org>,
	"Jun Nakajima" <jun.nakajima@intel.com>,
	"Kevin Tian" <kevin.tian@intel.com>,
	"Tamas K Lengyel" <tamas@tklengyel.com>,
	Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v7 05/10] x86/vmx: Add Intel Processor Trace support
Date: Tue, 26 Jan 2021 14:35:56 +0100	[thread overview]
Message-ID: <9fa8ff47-cd09-a09b-6d62-bb47f72c3847@suse.com> (raw)
In-Reply-To: <20210121212718.2441-6-andrew.cooper3@citrix.com>

On 21.01.2021 22:27, Andrew Cooper wrote:
> From: Michał Leszczyński <michal.leszczynski@cert.pl>
> 
> Add CPUID/MSR enumeration details for Processor Trace.  For now, we will only
> support its use inside VMX operation.  Fill in the vmtrace_available boolean
> to activate the newly introduced common infrastructure for allocating trace
> buffers.
> 
> For now, Processor Trace is going to be operated in Single Output mode behind
> the guests back.  Add the MSRs to struct vcpu_msrs, and set up the buffer
> limit in vmx_init_pt() as it is fixed for the lifetime of the domain.
> 
> Context switch the most of the MSRs in and out of vCPU context switch, but the
> main control register needs to reside in the MSR load/save lists.  Explicitly
> pull the msrs pointer out into a local variable, because the optimiser cannot
> keep it live across the memory clobbers in the MSR accesses.
> 
> Signed-off-by: Michał Leszczyński <michal.leszczynski@cert.pl>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>
albeit with a few things to consider and with a question to
confirm my understanding.

> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -291,6 +291,20 @@ static int vmx_init_vmcs_config(void)
>          _vmx_cpu_based_exec_control &=
>              ~(CPU_BASED_CR8_LOAD_EXITING | CPU_BASED_CR8_STORE_EXITING);
>  
> +    rdmsrl(MSR_IA32_VMX_MISC, _vmx_misc_cap);
> +
> +    /* Check whether IPT is supported in VMX operation. */
> +    if ( !smp_processor_id() )

I'm not happy to see another one of these appear. I'd prefer
if the caller passed its "bsp" boolean into here, or if this
was made use system_state.

> +        vmtrace_available = cpu_has_proc_trace &&
> +                            (_vmx_misc_cap & VMX_MISC_PROC_TRACE);
> +    else if ( vmtrace_available &&
> +              !(_vmx_misc_cap & VMX_MISC_PROC_TRACE) )
> +    {
> +        printk("VMX: IPT capabilities differ between CPU%u and CPU0\n",

As a minor follow-on, instead of "CPU0" this may then want
to say "rest of the system" or "BSP", but I can see that at
least the former is also making the message longer (which
may not be desirable).

> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -428,6 +428,20 @@ static void vmx_domain_relinquish_resources(struct domain *d)
>      vmx_free_vlapic_mapping(d);
>  }
>  
> +static void vmx_init_pt(struct vcpu *v)

We use "pt" already as an acronym for pass-through. Could we
use "ipt" here, for example (following the new "ipt_active"
field)?

> --- a/xen/include/asm-x86/msr.h
> +++ b/xen/include/asm-x86/msr.h
> @@ -306,6 +306,38 @@ struct vcpu_msrs
>          };
>      } misc_features_enables;
>  
> +    /*
> +     * 0x00000560 ... 57x - MSR_RTIT_*
> +     *
> +     * "Real Time Instruction Trace", now called Processor Trace.
> +     *
> +     * These MSRs are not exposed to guests.  They are controlled by Xen
> +     * behind the scenes, when vmtrace is enabled for the domain.
> +     *
> +     * MSR_RTIT_OUTPUT_BASE not stored here.  It is fixed per vcpu, and
> +     * derived from v->vmtrace.buf.
> +     */
> +    struct {
> +        /*
> +         * Placed in the MSR load/save lists.  Only modified by hypercall in
> +         * the common case.
> +         */
> +        uint64_t ctl;

IIUC this field will be used by subsequent patches only?

Jan


  reply	other threads:[~2021-01-26 13:36 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-21 21:27 [PATCH v7 00/10] Implement support for external IPT monitoring Andrew Cooper
2021-01-21 21:27 ` [PATCH v7 01/10] xen+tools: Introduce XEN_SYSCTL_PHYSCAP_vmtrace Andrew Cooper
2021-01-22 15:28   ` Ian Jackson
2021-01-26  8:58   ` Julien Grall
2021-01-26 10:04     ` Andrew Cooper
2021-01-21 21:27 ` [PATCH v7 02/10] xen/domain: Add vmtrace_frames domain creation parameter Andrew Cooper
2021-01-25 15:08   ` Jan Beulich
2021-01-25 17:17     ` Andrew Cooper
2021-01-26 10:51       ` Jan Beulich
2021-01-29 16:37     ` Jan Beulich
2021-01-21 21:27 ` [PATCH v7 03/10] tools/[lib]xl: Add vmtrace_buf_size parameter Andrew Cooper
2021-01-22 15:29   ` Ian Jackson
2021-01-21 21:27 ` [PATCH v7 04/10] xen/memory: Add a vmtrace_buf resource type Andrew Cooper
2021-01-25 16:31   ` Jan Beulich
2021-01-26  7:37     ` Jan Beulich
2021-01-26  9:58       ` Andrew Cooper
2021-01-26 10:30         ` Jan Beulich
2021-01-21 21:27 ` [PATCH v7 05/10] x86/vmx: Add Intel Processor Trace support Andrew Cooper
2021-01-26 13:35   ` Jan Beulich [this message]
2021-01-29 22:08     ` Andrew Cooper
2021-01-21 21:27 ` [PATCH v7 06/10] xen/domctl: Add XEN_DOMCTL_vmtrace_op Andrew Cooper
2021-01-26 14:18   ` Jan Beulich
2021-01-29 23:01     ` Andrew Cooper
2021-01-21 21:27 ` [PATCH v7 07/10] tools/libxc: Add xc_vmtrace_* functions Andrew Cooper
2021-01-22 15:29   ` Ian Jackson
2021-01-21 21:27 ` [PATCH v7 08/10] tools/misc: Add xen-vmtrace tool Andrew Cooper
2021-01-22 15:33   ` Ian Jackson
2021-01-25 15:30     ` Andrew Cooper
2021-01-26 11:59       ` Ian Jackson
2021-01-26 12:55         ` Andrew Cooper
2021-01-26 13:32           ` Ian Jackson
2021-01-26 15:59             ` Andrew Cooper
2021-01-21 21:27 ` [PATCH v7 09/10] xen/vmtrace: support for VM forks Andrew Cooper
2021-01-26 14:21   ` Jan Beulich
2021-01-27 15:50     ` Lengyel, Tamas
2021-01-21 21:27 ` [PATCH v7 10/10] x86/vm_event: Carry Processor Trace buffer offset in vm_event Andrew Cooper
2021-01-26 14:27   ` Jan Beulich
2021-01-29 23:22     ` Andrew Cooper
2021-01-29 23:40       ` Tamas K Lengyel
2021-02-01  8:55         ` Jan Beulich
2021-02-01  9:06           ` Andrew Cooper

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=9fa8ff47-cd09-a09b-6d62-bb47f72c3847@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jun.nakajima@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=michal.leszczynski@cert.pl \
    --cc=roger.pau@citrix.com \
    --cc=tamas@tklengyel.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.