linux-kernel - linux-next: manual merge of the kvm tree with the tip tree

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20220110131642.75375b09@canb.auug.org.au>
Date:   Mon, 10 Jan 2022 13:16:42 +1100
From:   Stephen Rothwell <sfr@...b.auug.org.au>
To:     Paolo Bonzini <pbonzini@...hat.com>, KVM <kvm@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     Like Xu <like.xu@...ux.intel.com>, Like Xu <likexu@...cent.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Sean Christopherson <seanjc@...gle.com>,
        Zhu Lingshan <lingshan.zhu@...el.com>
Subject: linux-next: manual merge of the kvm tree with the tip tree

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/kvm/pmu.c

between commits:

  b9f5621c9547 ("perf/core: Rework guest callbacks to prepare for static_call support")
  73cd107b9685 ("KVM: x86: Drop current_vcpu for kvm_running_vcpu + kvm_arch_vcpu variable")

from the tip tree and commit:

  40ccb96d5483 ("KVM: x86/pmu: Add pmc->intr to refactor kvm_perf_overflow{_intr}()")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kvm/pmu.c
index 0c2133eb4cf6,8abdadb7e22a..000000000000
--- a/arch/x86/kvm/pmu.c
+++ b/arch/x86/kvm/pmu.c
@@@ -55,43 -55,41 +55,41 @@@ static void kvm_pmi_trigger_fn(struct i
  	kvm_pmu_deliver_pmi(vcpu);
  }
  
- static void kvm_perf_overflow(struct perf_event *perf_event,
- 			      struct perf_sample_data *data,
- 			      struct pt_regs *regs)
+ static inline void __kvm_perf_overflow(struct kvm_pmc *pmc, bool in_pmi)
  {
- 	struct kvm_pmc *pmc = perf_event->overflow_handler_context;
  	struct kvm_pmu *pmu = pmc_to_pmu(pmc);
  
- 	if (!test_and_set_bit(pmc->idx, pmu->reprogram_pmi)) {
- 		__set_bit(pmc->idx, (unsigned long *)&pmu->global_status);
- 		kvm_make_request(KVM_REQ_PMU, pmc->vcpu);
- 	}
+ 	/* Ignore counters that have been reprogrammed already. */
+ 	if (test_and_set_bit(pmc->idx, pmu->reprogram_pmi))
+ 		return;
+ 
+ 	__set_bit(pmc->idx, (unsigned long *)&pmu->global_status);
+ 	kvm_make_request(KVM_REQ_PMU, pmc->vcpu);
+ 
+ 	if (!pmc->intr)
+ 		return;
+ 
+ 	/*
+ 	 * Inject PMI. If vcpu was in a guest mode during NMI PMI
+ 	 * can be ejected on a guest mode re-entry. Otherwise we can't
+ 	 * be sure that vcpu wasn't executing hlt instruction at the
+ 	 * time of vmexit and is not going to re-enter guest mode until
+ 	 * woken up. So we should wake it, but this is impossible from
+ 	 * NMI context. Do it from irq work instead.
+ 	 */
 -	if (in_pmi && !kvm_is_in_guest())
++	if (in_pmi && !kvm_handling_nmi_from_guest(pmc->vcpu))
+ 		irq_work_queue(&pmc_to_pmu(pmc)->irq_work);
+ 	else
+ 		kvm_make_request(KVM_REQ_PMI, pmc->vcpu);
  }
  
- static void kvm_perf_overflow_intr(struct perf_event *perf_event,
- 				   struct perf_sample_data *data,
- 				   struct pt_regs *regs)
+ static void kvm_perf_overflow(struct perf_event *perf_event,
+ 			      struct perf_sample_data *data,
+ 			      struct pt_regs *regs)
  {
  	struct kvm_pmc *pmc = perf_event->overflow_handler_context;
- 	struct kvm_pmu *pmu = pmc_to_pmu(pmc);
- 
- 	if (!test_and_set_bit(pmc->idx, pmu->reprogram_pmi)) {
- 		__set_bit(pmc->idx, (unsigned long *)&pmu->global_status);
- 		kvm_make_request(KVM_REQ_PMU, pmc->vcpu);
  
- 		/*
- 		 * Inject PMI. If vcpu was in a guest mode during NMI PMI
- 		 * can be ejected on a guest mode re-entry. Otherwise we can't
- 		 * be sure that vcpu wasn't executing hlt instruction at the
- 		 * time of vmexit and is not going to re-enter guest mode until
- 		 * woken up. So we should wake it, but this is impossible from
- 		 * NMI context. Do it from irq work instead.
- 		 */
- 		if (!kvm_handling_nmi_from_guest(pmc->vcpu))
- 			irq_work_queue(&pmc_to_pmu(pmc)->irq_work);
- 		else
- 			kvm_make_request(KVM_REQ_PMI, pmc->vcpu);
- 	}
+ 	__kvm_perf_overflow(pmc, true);
  }
  
  static void pmc_reprogram_counter(struct kvm_pmc *pmc, u32 type,

Content of type "application/pgp-signature" skipped