linux-kernel - Re: [PATCH v1] KVM/x86/vPMU: Guest PMI Optimization

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181013133013.GA15612@worktop.programming.kicks-ass.net>
Date:   Sat, 13 Oct 2018 15:30:13 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Wei Wang <wei.w.wang@...el.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        pbonzini@...hat.com, ak@...ux.intel.com, mingo@...hat.com,
        rkrcmar@...hat.com, like.xu@...el.com
Subject: Re: [PATCH v1] KVM/x86/vPMU: Guest PMI Optimization

On Fri, Oct 12, 2018 at 08:20:17PM +0800, Wei Wang wrote:
> Guest changing MSR_CORE_PERF_GLOBAL_CTRL causes KVM to reprogram pmc
> counters, which re-allocates a host perf event. This process is

Yea gawds, that's horrific. Why does it do that? We have
PERF_EVENT_IOC_PERIOD which does that much better. Still, what you're
proposing is faster still -- if it is correct.

> This patch implements a fast path to handle the guest change of
> MSR_CORE_PERF_GLOBAL_CTRL for the guest pmi case. Guest change of the
> msr will be applied to the hardware when entering the guest, and the
> old perf event will continue to be used. The guest setting of the
> perf counter for the next irq period in pmi will also be written
> directly to the hardware counter when entering the guest.

What you're failing to explain here is why exactly it is ok to write to
the MSR directly without updating the perf_event state. I didn't take
the time to go through all that, but it certainly needs documenting.

This is something that can certainly get broken by accident.

Is there any documentation/comment that explains how this virtual PMU
crud works in general?

> +u64 intel_pmu_disable_guest_counters(void)
> +{
> +	struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
> +	u64 mask = cpuc->intel_ctrl_host_mask;
> +
> +	cpuc->intel_ctrl_host_mask = ULONG_MAX;
> +
> +	return mask;
> +}
> +EXPORT_SYMBOL_GPL(intel_pmu_disable_guest_counters);

OK, this them gets the MSR written when we re-enter the guest, after the
WRMSR trap, right?

> diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
> index 58ead7d..210e5df 100644
> --- a/arch/x86/kvm/pmu.c
> +++ b/arch/x86/kvm/pmu.c
> @@ -80,6 +80,7 @@ static void kvm_perf_overflow_intr(struct perf_event *perf_event,
>  			      (unsigned long *)&pmu->reprogram_pmi)) {
>  		__set_bit(pmc->idx, (unsigned long *)&pmu->global_status);
>  		kvm_make_request(KVM_REQ_PMU, pmc->vcpu);
> +		pmu->in_pmi = true;
>  
>  		/*
>  		 * Inject PMI. If vcpu was in a guest mode during NMI PMI
> diff --git a/arch/x86/kvm/pmu_intel.c b/arch/x86/kvm/pmu_intel.c
> index 5ab4a36..5f6ac3c 100644
> --- a/arch/x86/kvm/pmu_intel.c
> +++ b/arch/x86/kvm/pmu_intel.c
> @@ -55,6 +55,27 @@ static void reprogram_fixed_counters(struct kvm_pmu *pmu, u64 data)
>  	pmu->fixed_ctr_ctrl = data;
>  }
>  
> +static void fast_global_ctrl_changed(struct kvm_pmu *pmu, u64 data)
> +{
> +	pmu->global_ctrl = data;
> +
> +	if (!data) {
> +		/*
> +		 * The guest PMI handler is asking for disabling all the perf
> +		 * counters
> +		 */
> +		pmu->counter_mask = intel_pmu_disable_guest_counters();
> +	} else {
> +		/*
> +		 * The guest PMI handler is asking for enabling the perf
> +		 * counters. This happens at the end of the guest PMI handler,
> +		 * so clear in_pmi.
> +		 */
> +		intel_pmu_enable_guest_counters(pmu->counter_mask);
> +		pmu->in_pmi = false;
> +	}
> +}

The v4 PMI handler does not in fact do that I think.

> @@ -237,9 +267,23 @@ static int intel_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
>  	default:
>  		if ((pmc = get_gp_pmc(pmu, msr, MSR_IA32_PERFCTR0)) ||
>  		    (pmc = get_fixed_pmc(pmu, msr))) {
> -			if (!msr_info->host_initiated)
> -				data = (s64)(s32)data;
> -			pmc->counter += data - pmc_read_counter(pmc);
> +			if (pmu->in_pmi) {
> +				/*
> +				 * Since we are not re-allocating a perf event
> +				 * to reconfigure the sampling time when the
> +				 * guest pmu is in PMI, just set the value to
> +				 * the hardware perf counter. Counting will
> +				 * continue after the guest enables the
> +				 * counter bit in MSR_CORE_PERF_GLOBAL_CTRL.
> +				 */
> +				struct hw_perf_event *hwc =
> +						&pmc->perf_event->hw;
> +				wrmsrl(hwc->event_base, data);

But all this relies on the event calling the overflow handler; how does
this not corrupt the event state such that x86_perf_event_set_period()
might decide that the generated PMI is a spurious one?

> +			} else {
> +				if (!msr_info->host_initiated)
> +					data = (s64)(s32)data;
> +				pmc->counter += data - pmc_read_counter(pmc);
> +			}
>  			return 0;
>  		} else if ((pmc = get_gp_pmc(pmu, msr, MSR_P6_EVNTSEL0))) {
>  			if (data == pmc->eventsel)
> -- 
> 2.7.4
>