public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Mi, Dapeng" <dapeng1.mi@linux.intel.com>
To: Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, Like Xu <like.xu.linux@gmail.com>,
	Mingwei Zhang <mizhang@google.com>,
	Zhenyu Wang <zhenyuw@linux.intel.com>,
	Zhang Xiong <xiong.y.zhang@intel.com>,
	Lv Zhiyuan <zhiyuan.lv@intel.com>,
	Dapeng Mi <dapeng1.mi@intel.com>
Subject: Re: [kvm-unit-tests PATCH 4/4] x86/pmu: Add a PEBS test to verify the host LBRs aren't leaked to the guest
Date: Thu, 7 Mar 2024 17:31:07 +0800	[thread overview]
Message-ID: <af3d790b-60d5-4375-a948-caaf16631fd9@linux.intel.com> (raw)
In-Reply-To: <20240306230153.786365-5-seanjc@google.com>


On 3/7/2024 7:01 AM, Sean Christopherson wrote:
> When using adaptive PEBS with LBR entries, verify that the LBR entries are
> all '0'.  If KVM fails to context switch LBRs, e.g. when the guest isn't
> using LBRs, as is the case in the pmu_pebs test, then adaptive PEBS can be
> used to read the *host* LBRs as the CPU doesn't enforce the VMX MSR bitmaps
> when generating PEBS records, i.e. ignores KVM's interception of reads to
> LBR MSRs.
>
> This testcase is best exercised by simultaneously utilizing LBRs in the
> host, e.g. by running "perf record -b -e instructions", so that there is
> non-zero data in the LBR MSRs.
>
> Cc: Like Xu <like.xu.linux@gmail.com>
> Cc: Mingwei Zhang <mizhang@google.com>
> Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
> Cc: Zhang Xiong <xiong.y.zhang@intel.com>
> Cc: Lv Zhiyuan <zhiyuan.lv@intel.com>
> Cc: Dapeng Mi <dapeng1.mi@intel.com>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> ---
>   x86/pmu_pebs.c | 13 +++++++++++++
>   1 file changed, 13 insertions(+)
>
> diff --git a/x86/pmu_pebs.c b/x86/pmu_pebs.c
> index 0e8d60c3..df8e736f 100644
> --- a/x86/pmu_pebs.c
> +++ b/x86/pmu_pebs.c
> @@ -299,6 +299,19 @@ static void check_pebs_records(u64 bitmask, u64 pebs_data_cfg, bool use_adaptive
>   		expected = pebs_idx_match && pebs_size_match && data_cfg_match;
>   		report(expected,
>   		       "PEBS record (written seq %d) is verified (including size, counters and cfg).", count);
> +		if (use_adaptive && (pebs_data_cfg & PEBS_DATACFG_LBRS)) {
> +			unsigned int lbrs_offset = get_pebs_record_size(pebs_data_cfg & ~PEBS_DATACFG_LBRS, true);
> +			struct lbr_entry *pebs_lbrs = cur_record + lbrs_offset;
> +			int i;
> +
> +			for (i = 0; i < MAX_NUM_LBR_ENTRY; i++) {
> +				if (!pebs_lbrs[i].from && !pebs_lbrs[i].to)
> +					continue;
> +
> +				report_fail("PEBS LBR record %u isn't empty, got from = '%lx', to = '%lx', info = '%lx'",
> +					    i, pebs_lbrs[i].from, pebs_lbrs[i].to, pebs_lbrs[i].info);
> +			}
> +		}
>   		cur_record = cur_record + pebs_record_size;
>   		count++;
>   	} while (expected && (void *)cur_record < (void *)ds->pebs_index);
Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com>

  parent reply	other threads:[~2024-03-07  9:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-06 23:01 [kvm-unit-tests PATCH 0/4] x86/pmu: PEBS fixes and new testcases Sean Christopherson
2024-03-06 23:01 ` [kvm-unit-tests PATCH 1/4] x86/pmu: Enable PEBS on fixed counters iff baseline PEBS is support Sean Christopherson
2024-03-07  9:22   ` Mi, Dapeng
2024-03-06 23:01 ` [kvm-unit-tests PATCH 2/4] x86/pmu: Iterate over adaptive PEBS flag combinations Sean Christopherson
2024-03-06 23:01 ` [kvm-unit-tests PATCH 3/4] x86/pmu: Test adaptive PEBS without any adaptive counters Sean Christopherson
2024-03-07  9:08   ` Like Xu
2024-03-07  9:28   ` Mi, Dapeng
2024-06-05 16:17     ` Sean Christopherson
2024-03-07 10:00   ` Mi, Dapeng
2024-03-06 23:01 ` [kvm-unit-tests PATCH 4/4] x86/pmu: Add a PEBS test to verify the host LBRs aren't leaked to the guest Sean Christopherson
2024-03-07  9:23   ` Like Xu
2024-03-07  9:31   ` Mi, Dapeng [this message]
2024-03-07  9:22 ` [kvm-unit-tests PATCH 0/4] x86/pmu: PEBS fixes and new testcases Mi, Dapeng
2024-06-05 23:20 ` Sean Christopherson
2024-06-06  0:51   ` Mi, Dapeng1

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=af3d790b-60d5-4375-a948-caaf16631fd9@linux.intel.com \
    --to=dapeng1.mi@linux.intel.com \
    --cc=dapeng1.mi@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=like.xu.linux@gmail.com \
    --cc=mizhang@google.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=xiong.y.zhang@intel.com \
    --cc=zhenyuw@linux.intel.com \
    --cc=zhiyuan.lv@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