All of lore.kernel.org
 help / color / mirror / Atom feed
* linux-next: manual merge of the kvm tree with the tip tree
@ 2020-07-17  5:25 Stephen Rothwell
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Rothwell @ 2020-07-17  5:25 UTC (permalink / raw)
  To: Paolo Bonzini, KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Andy Lutomirski, Vitaly Kuznetsov

[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]

Hi all,

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

  arch/x86/kernel/kvm.c

between commit:

  b037b09b9058 ("x86/entry: Rename idtentry_enter/exit_cond_rcu() to idtentry_enter/exit()")

from the tip tree and commit:

  b1d405751cd5 ("KVM: x86: Switch KVM guest to using interrupts for page ready APF delivery")

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/kernel/kvm.c
index 3f78482d9496,d9995931ea18..000000000000
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@@ -232,18 -235,13 +235,13 @@@ EXPORT_SYMBOL_GPL(kvm_read_and_reset_ap
  
  noinstr bool __kvm_handle_async_pf(struct pt_regs *regs, u32 token)
  {
- 	u32 reason = kvm_read_and_reset_apf_flags();
+ 	u32 flags = kvm_read_and_reset_apf_flags();
 -	bool rcu_exit;
 +	idtentry_state_t state;
  
- 	switch (reason) {
- 	case KVM_PV_REASON_PAGE_NOT_PRESENT:
- 	case KVM_PV_REASON_PAGE_READY:
- 		break;
- 	default:
+ 	if (!flags)
  		return false;
- 	}
  
 -	rcu_exit = idtentry_enter_cond_rcu(regs);
 +	state = idtentry_enter(regs);
  	instrumentation_begin();
  
  	/*

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2022-12-01  0:18 Stephen Rothwell
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Rothwell @ 2022-12-01  0:18 UTC (permalink / raw)
  To: Paolo Bonzini, KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Dave Hansen, Kai Huang, Linux Kernel Mailing List,
	Linux Next Mailing List, Sean Christopherson

[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]

Hi all,

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

  arch/x86/kvm/cpuid.c

between commit:

  16a7fe3728a8 ("KVM/VMX: Allow exposing EDECCSSA user leaf function to KVM guest")

from the tip tree and commit:

  047c72299061 ("KVM: x86: Update KVM-only leaf handling to allow for 100% KVM-only leafs")

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/cpuid.c
index c92c49a0b35b,723502181a3a..000000000000
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@@ -664,8 -675,8 +675,8 @@@ void kvm_set_cpu_caps(void
  		F(XSAVEOPT) | F(XSAVEC) | F(XGETBV1) | F(XSAVES) | f_xfd
  	);
  
- 	kvm_cpu_cap_init_scattered(CPUID_12_EAX,
+ 	kvm_cpu_cap_init_kvm_defined(CPUID_12_EAX,
 -		SF(SGX1) | SF(SGX2)
 +		SF(SGX1) | SF(SGX2) | SF(SGX_EDECCSSA)
  	);
  
  	kvm_cpu_cap_mask(CPUID_8000_0001_ECX,

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2022-12-01  0:14 Stephen Rothwell
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Rothwell @ 2022-12-01  0:14 UTC (permalink / raw)
  To: Paolo Bonzini, KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Chang S. Bae, Dave Hansen, Jiaxi Chen, Kirill A. Shutemov,
	Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 1787 bytes --]

Hi all,

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

  arch/x86/include/asm/cpufeatures.h

between commit:

  aa387b1b1e66 ("x86: CPUID and CR3/CR4 flags for Linear Address Masking")

from the tip tree and commits:

  6a19d7aa5821 ("x86: KVM: Advertise CMPccXADD CPUID to user space")
  af2872f62254 ("x86: KVM: Advertise AMX-FP16 CPUID to user space")
  5e85c4ebf206 ("x86: KVM: Advertise AVX-IFMA CPUID to user space")

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/include/asm/cpufeatures.h
index 11a0e06362e4,1419c4e04d45..000000000000
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@@ -311,7 -308,9 +311,10 @@@
  /* Intel-defined CPU features, CPUID level 0x00000007:1 (EAX), word 12 */
  #define X86_FEATURE_AVX_VNNI		(12*32+ 4) /* AVX VNNI instructions */
  #define X86_FEATURE_AVX512_BF16		(12*32+ 5) /* AVX512 BFLOAT16 instructions */
+ #define X86_FEATURE_CMPCCXADD           (12*32+ 7) /* "" CMPccXADD instructions */
+ #define X86_FEATURE_AMX_FP16		(12*32+21) /* "" AMX fp16 Support */
+ #define X86_FEATURE_AVX_IFMA            (12*32+23) /* "" Support for VPMADD52[H,L]UQ */
 +#define X86_FEATURE_LAM			(12*32+26) /* Linear Address Masking */
  
  /* AMD-defined CPU features, CPUID level 0x80000008 (EBX), word 13 */
  #define X86_FEATURE_CLZERO		(13*32+ 0) /* CLZERO instruction */

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: linux-next: manual merge of the kvm tree with the tip tree
  2022-01-10  2:16 Stephen Rothwell
@ 2022-01-10  2:28 ` Like Xu
  0 siblings, 0 replies; 49+ messages in thread
From: Like Xu @ 2022-01-10  2:28 UTC (permalink / raw)
  To: Stephen Rothwell, Paolo Bonzini
  Cc: Like Xu, Like Xu, Linux Kernel Mailing List,
	Linux Next Mailing List, Sean Christopherson, Zhu Lingshan, KVM,
	Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra

On 10/1/2022 10:16 am, Stephen Rothwell wrote:
> 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.
> 

The fix looks good to me. Thank you and please move on.

^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2022-01-10  2:16 Stephen Rothwell
  2022-01-10  2:28 ` Like Xu
  0 siblings, 1 reply; 49+ messages in thread
From: Stephen Rothwell @ 2022-01-10  2:16 UTC (permalink / raw)
  To: Paolo Bonzini, KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Like Xu, Like Xu, Linux Kernel Mailing List,
	Linux Next Mailing List, Sean Christopherson, Zhu Lingshan

[-- Attachment #1: Type: text/plain, Size: 3747 bytes --]

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,

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: linux-next: manual merge of the kvm tree with the tip tree
  2021-12-13 17:46 broonie
  2021-12-13 18:14 ` Paolo Bonzini
@ 2021-12-13 18:23 ` Mark Brown
  1 sibling, 0 replies; 49+ messages in thread
From: Mark Brown @ 2021-12-13 18:23 UTC (permalink / raw)
  To: Paolo Bonzini, KVM
  Cc: David Woodhouse, Linux Kernel Mailing List,
	Linux Next Mailing List, Peter Zijlstra, Sean Christopherson

[-- Attachment #1: Type: text/plain, Size: 434 bytes --]

On Mon, Dec 13, 2021 at 05:46:28PM +0000, broonie@kernel.org wrote:

> - kvm-y := $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o \
> - 	 $(KVM)/vfio.o $(KVM)/irqchip.o $(KVM)/binary_stats.o \
> - 	 arm.o mmu.o mmio.o psci.o hypercalls.o pvtime.o \
>  -kvm-y += arm.o mmu.o mmio.o psci.o perf.o hypercalls.o pvtime.o \
> ++kvm-y := arm.o mmu.o mmio.o psci.o hypercalls.o pvtime.o \

This should of course have used the +=.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: linux-next: manual merge of the kvm tree with the tip tree
  2021-12-13 17:46 broonie
@ 2021-12-13 18:14 ` Paolo Bonzini
  2021-12-13 18:23 ` Mark Brown
  1 sibling, 0 replies; 49+ messages in thread
From: Paolo Bonzini @ 2021-12-13 18:14 UTC (permalink / raw)
  To: broonie, KVM
  Cc: David Woodhouse, Linux Kernel Mailing List,
	Linux Next Mailing List, Peter Zijlstra, Sean Christopherson

On 12/13/21 18:46, broonie@kernel.org wrote:
> 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.
> 
> diff --cc arch/arm64/kvm/Makefile
> index 0bcc378b79615,04a53f71a6b63..0000000000000
> --- a/arch/arm64/kvm/Makefile
> +++ b/arch/arm64/kvm/Makefile
> @@@ -10,9 -10,7 +10,7 @@@ include $(srctree)/virt/kvm/Makefile.kv
>    obj-$(CONFIG_KVM) += kvm.o
>    obj-$(CONFIG_KVM) += hyp/
>    
> - kvm-y := $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o \
> - 	 $(KVM)/vfio.o $(KVM)/irqchip.o $(KVM)/binary_stats.o \
> - 	 arm.o mmu.o mmio.o psci.o hypercalls.o pvtime.o \
>   -kvm-y += arm.o mmu.o mmio.o psci.o perf.o hypercalls.o pvtime.o \
> ++kvm-y := arm.o mmu.o mmio.o psci.o hypercalls.o pvtime.o \

This is mostly okay, but it needs to be "+=" instead of ":=".

Paolo

^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2021-12-13 17:46 broonie
  2021-12-13 18:14 ` Paolo Bonzini
  2021-12-13 18:23 ` Mark Brown
  0 siblings, 2 replies; 49+ messages in thread
From: broonie @ 2021-12-13 17:46 UTC (permalink / raw)
  To: Paolo Bonzini, KVM
  Cc: David Woodhouse, Linux Kernel Mailing List,
	Linux Next Mailing List, Peter Zijlstra, Sean Christopherson

Hi all,

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

  arch/arm64/kvm/Makefile

between commit:

  17ed14eba22b3 ("KVM: arm64: Drop perf.c and fold its tiny bits of code into arm.c")

from the tip tree and commit:

  d8f6ef45a623d ("KVM: arm64: Use Makefile.kvm for common files")

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.

diff --cc arch/arm64/kvm/Makefile
index 0bcc378b79615,04a53f71a6b63..0000000000000
--- a/arch/arm64/kvm/Makefile
+++ b/arch/arm64/kvm/Makefile
@@@ -10,9 -10,7 +10,7 @@@ include $(srctree)/virt/kvm/Makefile.kv
  obj-$(CONFIG_KVM) += kvm.o
  obj-$(CONFIG_KVM) += hyp/
  
- kvm-y := $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o \
- 	 $(KVM)/vfio.o $(KVM)/irqchip.o $(KVM)/binary_stats.o \
- 	 arm.o mmu.o mmio.o psci.o hypercalls.o pvtime.o \
 -kvm-y += arm.o mmu.o mmio.o psci.o perf.o hypercalls.o pvtime.o \
++kvm-y := arm.o mmu.o mmio.o psci.o hypercalls.o pvtime.o \
  	 inject_fault.o va_layout.o handle_exit.o \
  	 guest.o debug.o reset.o sys_regs.o \
  	 vgic-sys-reg-v3.o fpsimd.o pmu.o \

^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2021-10-25  5:11 Stephen Rothwell
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Rothwell @ 2021-10-25  5:11 UTC (permalink / raw)
  To: Paolo Bonzini, KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Borislav Petkov, Linux Kernel Mailing List,
	Linux Next Mailing List, Sean Christopherson

[-- Attachment #1: Type: text/plain, Size: 2710 bytes --]

Hi all,

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

  arch/x86/kvm/x86.c

between commits:

  d69c1382e1b7 ("x86/kvm: Convert FPU handling to a single swap buffer")
  126fe0401883 ("x86/fpu: Cleanup xstate xcomp_bv initialization")

from the tip tree and commits:

  e8f65b9bb483 ("KVM: x86: Remove defunct setting of XCR0 for guest during vCPU create")
  583d369b36a9 ("KVM: x86: Fold fx_init() into kvm_arch_vcpu_create()")

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/x86.c
index 5f1fc8224414,ac83d873d65b..000000000000
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@@ -10477,16 -10869,15 +10722,6 @@@ static int sync_regs(struct kvm_vcpu *v
  	return 0;
  }
  
- static void fx_init(struct kvm_vcpu *vcpu)
 -void kvm_free_guest_fpu(struct kvm_vcpu *vcpu)
--{
- 	/*
- 	 * Ensure guest xcr0 is valid for loading
- 	 */
- 	vcpu->arch.xcr0 = XFEATURE_MASK_FP;
- 
- 	vcpu->arch.cr0 |= X86_CR0_ET;
 -	if (vcpu->arch.guest_fpu) {
 -		kmem_cache_free(x86_fpu_cache, vcpu->arch.guest_fpu);
 -		vcpu->arch.guest_fpu = NULL;
 -	}
--}
 -EXPORT_SYMBOL_GPL(kvm_free_guest_fpu);
--
  int kvm_arch_vcpu_precreate(struct kvm *kvm, unsigned int id)
  {
  	if (kvm_check_tsc_unstable() && atomic_read(&kvm->online_vcpus) != 0)
@@@ -10543,13 -10934,24 +10778,11 @@@ int kvm_arch_vcpu_create(struct kvm_vcp
  	if (!alloc_emulate_ctxt(vcpu))
  		goto free_wbinvd_dirty_mask;
  
 -	vcpu->arch.user_fpu = kmem_cache_zalloc(x86_fpu_cache,
 -						GFP_KERNEL_ACCOUNT);
 -	if (!vcpu->arch.user_fpu) {
 -		pr_err("kvm: failed to allocate userspace's fpu\n");
 -		goto free_emulate_ctxt;
 -	}
 -
 -	vcpu->arch.guest_fpu = kmem_cache_zalloc(x86_fpu_cache,
 -						 GFP_KERNEL_ACCOUNT);
 -	if (!vcpu->arch.guest_fpu) {
 +	if (!fpu_alloc_guest_fpstate(&vcpu->arch.guest_fpu)) {
  		pr_err("kvm: failed to allocate vcpu's fpu\n");
 -		goto free_user_fpu;
 +		goto free_emulate_ctxt;
  	}
 -	fpstate_init(&vcpu->arch.guest_fpu->state);
 -	if (boot_cpu_has(X86_FEATURE_XSAVES))
 -		vcpu->arch.guest_fpu->state.xsave.header.xcomp_bv =
 -			host_xcr0 | XSTATE_COMPACTION_ENABLED;
  
- 	fx_init(vcpu);
- 
  	vcpu->arch.maxphyaddr = cpuid_query_maxphyaddr(vcpu);
  	vcpu->arch.reserved_gpa_bits = kvm_vcpu_reserved_gpa_bits_raw(vcpu);
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: linux-next: manual merge of the kvm tree with the tip tree
  2021-10-21  2:39 Stephen Rothwell
@ 2021-10-21 15:32 ` Borislav Petkov
  0 siblings, 0 replies; 49+ messages in thread
From: Borislav Petkov @ 2021-10-21 15:32 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Paolo Bonzini, KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux Kernel Mailing List,
	Linux Next Mailing List, Sean Christopherson

On Thu, Oct 21, 2021 at 01:39:31PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>   arch/x86/kvm/x86.c
> 
> between commit:
> 
>   126fe0401883 ("x86/fpu: Cleanup xstate xcomp_bv initialization")
> 
> from the tip tree and commits:
> 
>   5ebbc470d7f3 ("KVM: x86: Remove defunct setting of CR0.ET for guests during vCPU create")
>   e8f65b9bb483 ("KVM: x86: Remove defunct setting of XCR0 for guest during vCPU create")
>   583d369b36a9 ("KVM: x86: Fold fx_init() into kvm_arch_vcpu_create()")
> 
> 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/x86.c
> index 04350680b649,3ea4f6ef2474..000000000000
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@@ -10615,10 -10687,10 +10590,9 @@@ int kvm_arch_vcpu_create(struct kvm_vcp
>   		pr_err("kvm: failed to allocate vcpu's fpu\n");
>   		goto free_user_fpu;
>   	}
>  -	fpstate_init(&vcpu->arch.guest_fpu->state);
>  -	if (boot_cpu_has(X86_FEATURE_XSAVES))
>  -		vcpu->arch.guest_fpu->state.xsave.header.xcomp_bv =
>  -			host_xcr0 | XSTATE_COMPACTION_ENABLED;
>  +
>  +	fpu_init_fpstate_user(vcpu->arch.user_fpu);
>  +	fpu_init_fpstate_user(vcpu->arch.guest_fpu);
> - 	fx_init(vcpu);
>   
>   	vcpu->arch.maxphyaddr = cpuid_query_maxphyaddr(vcpu);
>   	vcpu->arch.reserved_gpa_bits = kvm_vcpu_reserved_gpa_bits_raw(vcpu);

LGTM too, thx Stephen!

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg

^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2021-10-21  2:39 Stephen Rothwell
  2021-10-21 15:32 ` Borislav Petkov
  0 siblings, 1 reply; 49+ messages in thread
From: Stephen Rothwell @ 2021-10-21  2:39 UTC (permalink / raw)
  To: Paolo Bonzini, KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Borislav Petkov, Linux Kernel Mailing List,
	Linux Next Mailing List, Sean Christopherson

[-- Attachment #1: Type: text/plain, Size: 1650 bytes --]

Hi all,

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

  arch/x86/kvm/x86.c

between commit:

  126fe0401883 ("x86/fpu: Cleanup xstate xcomp_bv initialization")

from the tip tree and commits:

  5ebbc470d7f3 ("KVM: x86: Remove defunct setting of CR0.ET for guests during vCPU create")
  e8f65b9bb483 ("KVM: x86: Remove defunct setting of XCR0 for guest during vCPU create")
  583d369b36a9 ("KVM: x86: Fold fx_init() into kvm_arch_vcpu_create()")

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/x86.c
index 04350680b649,3ea4f6ef2474..000000000000
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@@ -10615,10 -10687,10 +10590,9 @@@ int kvm_arch_vcpu_create(struct kvm_vcp
  		pr_err("kvm: failed to allocate vcpu's fpu\n");
  		goto free_user_fpu;
  	}
 -	fpstate_init(&vcpu->arch.guest_fpu->state);
 -	if (boot_cpu_has(X86_FEATURE_XSAVES))
 -		vcpu->arch.guest_fpu->state.xsave.header.xcomp_bv =
 -			host_xcr0 | XSTATE_COMPACTION_ENABLED;
 +
 +	fpu_init_fpstate_user(vcpu->arch.user_fpu);
 +	fpu_init_fpstate_user(vcpu->arch.guest_fpu);
- 	fx_init(vcpu);
  
  	vcpu->arch.maxphyaddr = cpuid_query_maxphyaddr(vcpu);
  	vcpu->arch.reserved_gpa_bits = kvm_vcpu_reserved_gpa_bits_raw(vcpu);

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: linux-next: manual merge of the kvm tree with the tip tree
  2021-04-22  4:45 ` Nadav Amit
  2021-04-22  4:58   ` Stephen Rothwell
@ 2021-04-22  6:29   ` Paolo Bonzini
  1 sibling, 0 replies; 49+ messages in thread
From: Paolo Bonzini @ 2021-04-22  6:29 UTC (permalink / raw)
  To: Nadav Amit, Stephen Rothwell
  Cc: KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Ingo Molnar, Linux Kernel Mailing List,
	Linux Next Mailing List, Wanpeng Li

On 22/04/21 06:45, Nadav Amit wrote:
> 
>> On Apr 21, 2021, at 9:30 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Hi all,
>>
>> Today's linux-next merge of the kvm tree got a conflict in:
>>
>>   arch/x86/kernel/kvm.c
>>
>> between commit:
>>
>>   4ce94eabac16 ("x86/mm/tlb: Flush remote and local TLBs concurrently")
>>
>> from the tip tree and commit:
>>
>>   2b519b5797d4 ("x86/kvm: Don't bother __pv_cpu_mask when !CONFIG_SMP")
>>
>> from the kvm tree.
> 
> Thank you and sorry for that.

No problem, this is a reasonable conflict to have.

Paolo

>>   static void __init kvm_smp_prepare_boot_cpu(void)
>>   {
>>   	/*
>> @@@ -655,15 -668,9 +673,9 @@@ static void __init kvm_guest_init(void
>>
>>   	if (kvm_para_has_feature(KVM_FEATURE_STEAL_TIME)) {
>>   		has_steal_clock = 1;
>> -		pv_ops.time.steal_clock = kvm_steal_clock;
>> +		static_call_update(pv_steal_clock, kvm_steal_clock);
> 
> I do not understand how this line ended in the merge fix though.
> 
> Not that it is correct or wrong, but it is not part of either of
> these 2 patches AFAIK.
> 


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: linux-next: manual merge of the kvm tree with the tip tree
  2021-04-22  4:45 ` Nadav Amit
@ 2021-04-22  4:58   ` Stephen Rothwell
  2021-04-22  6:29   ` Paolo Bonzini
  1 sibling, 0 replies; 49+ messages in thread
From: Stephen Rothwell @ 2021-04-22  4:58 UTC (permalink / raw)
  To: Nadav Amit
  Cc: Stephen Rothwell, Paolo Bonzini, KVM, Thomas Gleixner,
	Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Ingo Molnar,
	Linux Kernel Mailing List, Linux Next Mailing List, Wanpeng Li

Hi Nadav,

On Thu, 22 Apr 2021 04:45:38 +0000 Nadav Amit <namit@vmware.com> wrote:
>
> >  static void __init kvm_smp_prepare_boot_cpu(void)
> >  {
> >  	/*
> > @@@ -655,15 -668,9 +673,9 @@@ static void __init kvm_guest_init(void
> > 
> >  	if (kvm_para_has_feature(KVM_FEATURE_STEAL_TIME)) {
> >  		has_steal_clock = 1;
> > -		pv_ops.time.steal_clock = kvm_steal_clock;
> > +		static_call_update(pv_steal_clock, kvm_steal_clock);  
> 
> I do not understand how this line ended in the merge fix though.
> 
> Not that it is correct or wrong, but it is not part of either of
> these 2 patches AFAIK.

It came from another patch that did not cause a conflict but ended up
in the diff output.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: linux-next: manual merge of the kvm tree with the tip tree
  2021-04-22  4:30 Stephen Rothwell
@ 2021-04-22  4:45 ` Nadav Amit
  2021-04-22  4:58   ` Stephen Rothwell
  2021-04-22  6:29   ` Paolo Bonzini
  0 siblings, 2 replies; 49+ messages in thread
From: Nadav Amit @ 2021-04-22  4:45 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Paolo Bonzini, KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Ingo Molnar, Linux Kernel Mailing List,
	Linux Next Mailing List, Wanpeng Li


> On Apr 21, 2021, at 9:30 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>  arch/x86/kernel/kvm.c
> 
> between commit:
> 
>  4ce94eabac16 ("x86/mm/tlb: Flush remote and local TLBs concurrently")
> 
> from the tip tree and commit:
> 
>  2b519b5797d4 ("x86/kvm: Don't bother __pv_cpu_mask when !CONFIG_SMP")
> 
> from the kvm tree.

Thank you and sorry for that.

>  static void __init kvm_smp_prepare_boot_cpu(void)
>  {
>  	/*
> @@@ -655,15 -668,9 +673,9 @@@ static void __init kvm_guest_init(void
> 
>  	if (kvm_para_has_feature(KVM_FEATURE_STEAL_TIME)) {
>  		has_steal_clock = 1;
> -		pv_ops.time.steal_clock = kvm_steal_clock;
> +		static_call_update(pv_steal_clock, kvm_steal_clock);

I do not understand how this line ended in the merge fix though.

Not that it is correct or wrong, but it is not part of either of
these 2 patches AFAIK.


^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2021-04-22  4:30 Stephen Rothwell
  2021-04-22  4:45 ` Nadav Amit
  0 siblings, 1 reply; 49+ messages in thread
From: Stephen Rothwell @ 2021-04-22  4:30 UTC (permalink / raw)
  To: Paolo Bonzini, KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Ingo Molnar, Linux Kernel Mailing List, Linux Next Mailing List,
	Nadav Amit, Wanpeng Li

[-- Attachment #1: Type: text/plain, Size: 3518 bytes --]

Hi all,

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

  arch/x86/kernel/kvm.c

between commit:

  4ce94eabac16 ("x86/mm/tlb: Flush remote and local TLBs concurrently")

from the tip tree and commit:

  2b519b5797d4 ("x86/kvm: Don't bother __pv_cpu_mask when !CONFIG_SMP")

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/kernel/kvm.c
index 5d32fa477a62,224a7a1ed6c3..000000000000
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@@ -574,6 -574,49 +574,54 @@@ static void kvm_smp_send_call_func_ipi(
  	}
  }
  
 -static void kvm_flush_tlb_others(const struct cpumask *cpumask,
++static void kvm_flush_tlb_multi(const struct cpumask *cpumask,
+ 			const struct flush_tlb_info *info)
+ {
+ 	u8 state;
+ 	int cpu;
+ 	struct kvm_steal_time *src;
+ 	struct cpumask *flushmask = this_cpu_cpumask_var_ptr(__pv_cpu_mask);
+ 
+ 	cpumask_copy(flushmask, cpumask);
+ 	/*
+ 	 * We have to call flush only on online vCPUs. And
+ 	 * queue flush_on_enter for pre-empted vCPUs
+ 	 */
+ 	for_each_cpu(cpu, flushmask) {
++		/*
++		 * The local vCPU is never preempted, so we do not explicitly
++		 * skip check for local vCPU - it will never be cleared from
++		 * flushmask.
++		 */
+ 		src = &per_cpu(steal_time, cpu);
+ 		state = READ_ONCE(src->preempted);
+ 		if ((state & KVM_VCPU_PREEMPTED)) {
+ 			if (try_cmpxchg(&src->preempted, &state,
+ 					state | KVM_VCPU_FLUSH_TLB))
+ 				__cpumask_clear_cpu(cpu, flushmask);
+ 		}
+ 	}
+ 
 -	native_flush_tlb_others(flushmask, info);
++	native_flush_tlb_multi(flushmask, info);
+ }
+ 
+ static __init int kvm_alloc_cpumask(void)
+ {
+ 	int cpu;
+ 
+ 	if (!kvm_para_available() || nopv)
+ 		return 0;
+ 
+ 	if (pv_tlb_flush_supported() || pv_ipi_supported())
+ 		for_each_possible_cpu(cpu) {
+ 			zalloc_cpumask_var_node(per_cpu_ptr(&__pv_cpu_mask, cpu),
+ 				GFP_KERNEL, cpu_to_node(cpu));
+ 		}
+ 
+ 	return 0;
+ }
+ arch_initcall(kvm_alloc_cpumask);
+ 
  static void __init kvm_smp_prepare_boot_cpu(void)
  {
  	/*
@@@ -655,15 -668,9 +673,9 @@@ static void __init kvm_guest_init(void
  
  	if (kvm_para_has_feature(KVM_FEATURE_STEAL_TIME)) {
  		has_steal_clock = 1;
 -		pv_ops.time.steal_clock = kvm_steal_clock;
 +		static_call_update(pv_steal_clock, kvm_steal_clock);
  	}
  
- 	if (pv_tlb_flush_supported()) {
- 		pv_ops.mmu.flush_tlb_multi = kvm_flush_tlb_multi;
- 		pv_ops.mmu.tlb_remove_table = tlb_remove_table;
- 		pr_info("KVM setup pv remote TLB flush\n");
- 	}
- 
  	if (kvm_para_has_feature(KVM_FEATURE_PV_EOI))
  		apic_set_eoi_write(kvm_guest_apic_eoi_write);
  
@@@ -673,6 -680,12 +685,12 @@@
  	}
  
  #ifdef CONFIG_SMP
+ 	if (pv_tlb_flush_supported()) {
 -		pv_ops.mmu.flush_tlb_others = kvm_flush_tlb_others;
++		pv_ops.mmu.flush_tlb_multi = kvm_flush_tlb_multi;
+ 		pv_ops.mmu.tlb_remove_table = tlb_remove_table;
+ 		pr_info("KVM setup pv remote TLB flush\n");
+ 	}
+ 
  	smp_ops.smp_prepare_boot_cpu = kvm_smp_prepare_boot_cpu;
  	if (pv_sched_yield_supported()) {
  		smp_ops.send_call_func_ipi = kvm_smp_send_call_func_ipi;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2020-07-29  6:47 Stephen Rothwell
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Rothwell @ 2020-07-29  6:47 UTC (permalink / raw)
  To: Paolo Bonzini, KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Andy Lutomirski, Vitaly Kuznetsov

[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]

Hi all,

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

  arch/x86/kernel/kvm.c

between commits:

  b037b09b9058 ("x86/entry: Rename idtentry_enter/exit_cond_rcu() to idtentry_enter/exit()")
  a27a0a55495c ("x86/entry: Cleanup idtentry_enter/exit")

from the tip tree and commits:

  b1d405751cd5 ("KVM: x86: Switch KVM guest to using interrupts for page ready APF delivery")
  26d05b368a5c ("Merge branch 'kvm-async-pf-int' into HEAD")

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/kernel/kvm.c
index 233c77d056c9,d9995931ea18..000000000000
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@@ -232,18 -235,13 +235,13 @@@ EXPORT_SYMBOL_GPL(kvm_read_and_reset_ap
  
  noinstr bool __kvm_handle_async_pf(struct pt_regs *regs, u32 token)
  {
- 	u32 reason = kvm_read_and_reset_apf_flags();
+ 	u32 flags = kvm_read_and_reset_apf_flags();
 -	bool rcu_exit;
 +	irqentry_state_t state;
  
- 	switch (reason) {
- 	case KVM_PV_REASON_PAGE_NOT_PRESENT:
- 	case KVM_PV_REASON_PAGE_READY:
- 		break;
- 	default:
+ 	if (!flags)
  		return false;
- 	}
  
 -	rcu_exit = idtentry_enter_cond_rcu(regs);
 +	state = irqentry_enter(regs);
  	instrumentation_begin();
  
  	/*

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: linux-next: manual merge of the kvm tree with the tip tree
  2020-06-02  4:53 Stephen Rothwell
@ 2020-06-04  3:09 ` Stephen Rothwell
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Rothwell @ 2020-06-04  3:09 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Paolo Bonzini, KVM, Linux Next Mailing List,
	Linux Kernel Mailing List, Vitaly Kuznetsov

[-- Attachment #1: Type: text/plain, Size: 2259 bytes --]

Hi all,

On Tue, 2 Jun 2020 14:53:58 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>   arch/x86/kernel/kvm.c
> 
> between commit:
> 
>   a707ae1a9bbb ("x86/entry: Switch page fault exception to IDTENTRY_RAW")
> 
> from the tip tree and commit:
> 
>   68fd66f100d1 ("KVM: x86: extend struct kvm_vcpu_pv_apf_data with token info")
> 
> 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/kernel/kvm.c
> index 07dc47359c4f,d6f22a3a1f7d..000000000000
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@@ -217,23 -218,23 +217,23 @@@ again
>   }
>   EXPORT_SYMBOL_GPL(kvm_async_pf_task_wake);
>   
> - u32 noinstr kvm_read_and_reset_pf_reason(void)
>  -u32 kvm_read_and_reset_apf_flags(void)
> ++u32 noinstr kvm_read_and_reset_apf_flags(void)
>   {
> - 	u32 reason = 0;
> + 	u32 flags = 0;
>   
>   	if (__this_cpu_read(apf_reason.enabled)) {
> - 		reason = __this_cpu_read(apf_reason.reason);
> - 		__this_cpu_write(apf_reason.reason, 0);
> + 		flags = __this_cpu_read(apf_reason.flags);
> + 		__this_cpu_write(apf_reason.flags, 0);
>   	}
>   
> - 	return reason;
> + 	return flags;
>   }
> - EXPORT_SYMBOL_GPL(kvm_read_and_reset_pf_reason);
> + EXPORT_SYMBOL_GPL(kvm_read_and_reset_apf_flags);
>  -NOKPROBE_SYMBOL(kvm_read_and_reset_apf_flags);
>   
>  -bool __kvm_handle_async_pf(struct pt_regs *regs, u32 token)
>  +noinstr bool __kvm_handle_async_pf(struct pt_regs *regs, u32 token)
>   {
> - 	u32 reason = kvm_read_and_reset_pf_reason();
> + 	u32 reason = kvm_read_and_reset_apf_flags();
>  +	bool rcu_exit;
>   
>   	switch (reason) {
>   	case KVM_PV_REASON_PAGE_NOT_PRESENT:

This is now a conflict between the tip tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2020-06-02  4:53 Stephen Rothwell
  2020-06-04  3:09 ` Stephen Rothwell
  0 siblings, 1 reply; 49+ messages in thread
From: Stephen Rothwell @ 2020-06-02  4:53 UTC (permalink / raw)
  To: Paolo Bonzini, KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Vitaly Kuznetsov

[-- Attachment #1: Type: text/plain, Size: 1935 bytes --]

Hi all,

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

  arch/x86/kernel/kvm.c

between commit:

  a707ae1a9bbb ("x86/entry: Switch page fault exception to IDTENTRY_RAW")

from the tip tree and commit:

  68fd66f100d1 ("KVM: x86: extend struct kvm_vcpu_pv_apf_data with token info")

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/kernel/kvm.c
index 07dc47359c4f,d6f22a3a1f7d..000000000000
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@@ -217,23 -218,23 +217,23 @@@ again
  }
  EXPORT_SYMBOL_GPL(kvm_async_pf_task_wake);
  
- u32 noinstr kvm_read_and_reset_pf_reason(void)
 -u32 kvm_read_and_reset_apf_flags(void)
++u32 noinstr kvm_read_and_reset_apf_flags(void)
  {
- 	u32 reason = 0;
+ 	u32 flags = 0;
  
  	if (__this_cpu_read(apf_reason.enabled)) {
- 		reason = __this_cpu_read(apf_reason.reason);
- 		__this_cpu_write(apf_reason.reason, 0);
+ 		flags = __this_cpu_read(apf_reason.flags);
+ 		__this_cpu_write(apf_reason.flags, 0);
  	}
  
- 	return reason;
+ 	return flags;
  }
- EXPORT_SYMBOL_GPL(kvm_read_and_reset_pf_reason);
+ EXPORT_SYMBOL_GPL(kvm_read_and_reset_apf_flags);
 -NOKPROBE_SYMBOL(kvm_read_and_reset_apf_flags);
  
 -bool __kvm_handle_async_pf(struct pt_regs *regs, u32 token)
 +noinstr bool __kvm_handle_async_pf(struct pt_regs *regs, u32 token)
  {
- 	u32 reason = kvm_read_and_reset_pf_reason();
+ 	u32 reason = kvm_read_and_reset_apf_flags();
 +	bool rcu_exit;
  
  	switch (reason) {
  	case KVM_PV_REASON_PAGE_NOT_PRESENT:

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2020-01-16  2:48 Stephen Rothwell
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Rothwell @ 2020-01-16  2:48 UTC (permalink / raw)
  To: Paolo Bonzini, Radim Krčmář,
	KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Sean Christopherson, Xiaoyao Li

[-- Attachment #1: Type: text/plain, Size: 4496 bytes --]

Hi all,

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

  arch/x86/include/asm/vmx.h

between commit:

  b39033f504a7 ("KVM: VMX: Use VMX_FEATURE_* flags to define VMCS control bits")

from the tip tree and commits:

  9dadc2f918df ("KVM: VMX: Rename INTERRUPT_PENDING to INTERRUPT_WINDOW")
  4e2a0bc56ad1 ("KVM: VMX: Rename NMI_PENDING to NMI_WINDOW")
  5e3d394fdd9e ("KVM: VMX: Fix the spelling of CPU_BASED_USE_TSC_OFFSETTING")

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/include/asm/vmx.h
index 9fbba31be825,d716fe938fc0..000000000000
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@@ -22,27 -19,27 +22,27 @@@
  /*
   * Definitions of Primary Processor-Based VM-Execution Controls.
   */
- #define CPU_BASED_VIRTUAL_INTR_PENDING          VMCS_CONTROL_BIT(VIRTUAL_INTR_PENDING)
- #define CPU_BASED_USE_TSC_OFFSETING             VMCS_CONTROL_BIT(TSC_OFFSETTING)
 -#define CPU_BASED_INTR_WINDOW_EXITING           0x00000004
 -#define CPU_BASED_USE_TSC_OFFSETTING            0x00000008
 -#define CPU_BASED_HLT_EXITING                   0x00000080
 -#define CPU_BASED_INVLPG_EXITING                0x00000200
 -#define CPU_BASED_MWAIT_EXITING                 0x00000400
 -#define CPU_BASED_RDPMC_EXITING                 0x00000800
 -#define CPU_BASED_RDTSC_EXITING                 0x00001000
 -#define CPU_BASED_CR3_LOAD_EXITING		0x00008000
 -#define CPU_BASED_CR3_STORE_EXITING		0x00010000
 -#define CPU_BASED_CR8_LOAD_EXITING              0x00080000
 -#define CPU_BASED_CR8_STORE_EXITING             0x00100000
 -#define CPU_BASED_TPR_SHADOW                    0x00200000
 -#define CPU_BASED_NMI_WINDOW_EXITING		0x00400000
 -#define CPU_BASED_MOV_DR_EXITING                0x00800000
 -#define CPU_BASED_UNCOND_IO_EXITING             0x01000000
 -#define CPU_BASED_USE_IO_BITMAPS                0x02000000
 -#define CPU_BASED_MONITOR_TRAP_FLAG             0x08000000
 -#define CPU_BASED_USE_MSR_BITMAPS               0x10000000
 -#define CPU_BASED_MONITOR_EXITING               0x20000000
 -#define CPU_BASED_PAUSE_EXITING                 0x40000000
 -#define CPU_BASED_ACTIVATE_SECONDARY_CONTROLS   0x80000000
++#define CPU_BASED_INTR_WINDOW_EXITING           VMCS_CONTROL_BIT(VIRTUAL_INTR_PENDING)
++#define CPU_BASED_USE_TSC_OFFSETTING            VMCS_CONTROL_BIT(TSC_OFFSETTING)
 +#define CPU_BASED_HLT_EXITING                   VMCS_CONTROL_BIT(HLT_EXITING)
 +#define CPU_BASED_INVLPG_EXITING                VMCS_CONTROL_BIT(INVLPG_EXITING)
 +#define CPU_BASED_MWAIT_EXITING                 VMCS_CONTROL_BIT(MWAIT_EXITING)
 +#define CPU_BASED_RDPMC_EXITING                 VMCS_CONTROL_BIT(RDPMC_EXITING)
 +#define CPU_BASED_RDTSC_EXITING                 VMCS_CONTROL_BIT(RDTSC_EXITING)
 +#define CPU_BASED_CR3_LOAD_EXITING		VMCS_CONTROL_BIT(CR3_LOAD_EXITING)
 +#define CPU_BASED_CR3_STORE_EXITING		VMCS_CONTROL_BIT(CR3_STORE_EXITING)
 +#define CPU_BASED_CR8_LOAD_EXITING              VMCS_CONTROL_BIT(CR8_LOAD_EXITING)
 +#define CPU_BASED_CR8_STORE_EXITING             VMCS_CONTROL_BIT(CR8_STORE_EXITING)
 +#define CPU_BASED_TPR_SHADOW                    VMCS_CONTROL_BIT(VIRTUAL_TPR)
- #define CPU_BASED_VIRTUAL_NMI_PENDING		VMCS_CONTROL_BIT(VIRTUAL_NMI_PENDING)
++#define CPU_BASED_NMI_WINDOW_EXITING		VMCS_CONTROL_BIT(VIRTUAL_NMI_PENDING)
 +#define CPU_BASED_MOV_DR_EXITING                VMCS_CONTROL_BIT(MOV_DR_EXITING)
 +#define CPU_BASED_UNCOND_IO_EXITING             VMCS_CONTROL_BIT(UNCOND_IO_EXITING)
 +#define CPU_BASED_USE_IO_BITMAPS                VMCS_CONTROL_BIT(USE_IO_BITMAPS)
 +#define CPU_BASED_MONITOR_TRAP_FLAG             VMCS_CONTROL_BIT(MONITOR_TRAP_FLAG)
 +#define CPU_BASED_USE_MSR_BITMAPS               VMCS_CONTROL_BIT(USE_MSR_BITMAPS)
 +#define CPU_BASED_MONITOR_EXITING               VMCS_CONTROL_BIT(MONITOR_EXITING)
 +#define CPU_BASED_PAUSE_EXITING                 VMCS_CONTROL_BIT(PAUSE_EXITING)
 +#define CPU_BASED_ACTIVATE_SECONDARY_CONTROLS   VMCS_CONTROL_BIT(SEC_CONTROLS)
  
  #define CPU_BASED_ALWAYSON_WITHOUT_TRUE_MSR	0x0401e172
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2018-12-19  4:12 Stephen Rothwell
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Rothwell @ 2018-12-19  4:12 UTC (permalink / raw)
  To: Paolo Bonzini, Radim Krčmář,
	KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Dave Hansen,
	Marc Orr

[-- Attachment #1: Type: text/plain, Size: 743 bytes --]

Hi all,

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

  arch/x86/kvm/x86.c

between commit:

  eb012ef3b4e3 ("x86: Remove Intel MPX")

from the tip tree and commit:

  b666a4b69739 ("kvm: x86: Dynamically allocate guest_fpu")

from the kvm tree.

I fixed it up (the former removed some code updated by the latter, so I
did that) 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2018-12-17  5:22 Stephen Rothwell
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Rothwell @ 2018-12-17  5:22 UTC (permalink / raw)
  To: Paolo Bonzini, Radim Krčmář,
	KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Sean Christopherson

[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]

Hi all,

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

  arch/x86/kvm/vmx.c

between commit:

  a97673a1c43d ("x86: Fix various typos in comments")

from the tip tree and commit:

  a821bab2d1ee ("KVM: VMX: Move VMX specific files to a "vmx" subdirectory")

from the kvm tree.

I fixed it up (I removed the file and then made the same changes to
the file in its new position (one change was already fixed)) 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 --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index b8fa74ce3af2..c90fffdc5a93 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -2214,7 +2214,7 @@ static __init int alloc_kvm_area(void)
 		 * vmcs->revision_id to KVM_EVMCS_VERSION instead of
 		 * revision_id reported by MSR_IA32_VMX_BASIC.
 		 *
-		 * However, even though not explictly documented by
+		 * However, even though not explicitly documented by
 		 * TLFS, VMXArea passed as VMXON argument should
 		 * still be marked with revision_id reported by
 		 * physical CPU.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply related	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2018-10-19  3:25 Stephen Rothwell
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Rothwell @ 2018-10-19  3:25 UTC (permalink / raw)
  To: Paolo Bonzini, Radim Krčmář,
	KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Arnaldo Carvalho de Melo, Vitaly Kuznetsov

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

Hi all,

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

  tools/include/uapi/linux/kvm.h

between commit:

  25fe15e54fe5 ("tools headers uapi: Sync kvm.h copy")

from the tip tree and commit:

  c939989d74e2 ("tools/headers: update kvm.h")

from the kvm tree.

I fixed it up (the latter is a superset of the former) 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: linux-next: manual merge of the kvm tree with the tip tree
  2018-08-08  3:54 Stephen Rothwell
@ 2018-08-15  4:27 ` Stephen Rothwell
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Rothwell @ 2018-08-15  4:27 UTC (permalink / raw)
  To: Paolo Bonzini, Radim Krčmář, KVM
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	Pavel Tatashin, Wanpeng Li

[-- Attachment #1: Type: text/plain, Size: 2042 bytes --]

Hi all,

On Wed, 8 Aug 2018 13:54:45 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Paolo pointed out a semantic conflict between the kvm tree and the tip
> tree in
> 
>   arch/x86/kernel/kvm.c
> 
> between commit:
> 
>   368a540e0232 ("x86/kvmclock: Remove memblock dependency")
> 
> from the tip tree and commit:
> 
>   d63bae079b64 ("KVM: X86: Add kvm hypervisor init time platform setup callback")
> 
> 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.
> 
> I applied the following (as suggested) after the automatic merge:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 8 Aug 2018 13:48:34 +1000
> Subject: [PATCH] kvm: x86: fix semantic conflict in platform init
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/x86/kernel/kvm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index 0906b8731393..e2499bad3209 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -714,13 +714,13 @@ static void __init kvm_apic_init(void)
>  static void __init kvm_init_platform(void)
>  {
>  	x86_platform.apic_post_init = kvm_apic_init;
> +	kvmclock_init();
>  }
>  
>  const __initconst struct hypervisor_x86 x86_hyper_kvm = {
>  	.name			= "KVM",
>  	.detect			= kvm_detect,
>  	.type			= X86_HYPER_KVM,
> -	.init.init_platform	= kvmclock_init,
>  	.init.guest_late_init	= kvm_guest_init,
>  	.init.x2apic_available	= kvm_para_available,
>  	.init.init_platform	= kvm_init_platform,
> -- 
> 2.18.0

This is now a conflict between Linus' tree and the kvm tree.
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2018-08-08  3:54 Stephen Rothwell
  2018-08-15  4:27 ` Stephen Rothwell
  0 siblings, 1 reply; 49+ messages in thread
From: Stephen Rothwell @ 2018-08-08  3:54 UTC (permalink / raw)
  To: Paolo Bonzini, Radim Krčmář,
	KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Pavel Tatashin, Wanpeng Li

[-- Attachment #1: Type: text/plain, Size: 1787 bytes --]

Hi all,

Paolo pointed out a semantic conflict between the kvm tree and the tip
tree in

  arch/x86/kernel/kvm.c

between commit:

  368a540e0232 ("x86/kvmclock: Remove memblock dependency")

from the tip tree and commit:

  d63bae079b64 ("KVM: X86: Add kvm hypervisor init time platform setup callback")

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.

I applied the following (as suggested) after the automatic merge:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 8 Aug 2018 13:48:34 +1000
Subject: [PATCH] kvm: x86: fix semantic conflict in platform init

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/kernel/kvm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 0906b8731393..e2499bad3209 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -714,13 +714,13 @@ static void __init kvm_apic_init(void)
 static void __init kvm_init_platform(void)
 {
 	x86_platform.apic_post_init = kvm_apic_init;
+	kvmclock_init();
 }
 
 const __initconst struct hypervisor_x86 x86_hyper_kvm = {
 	.name			= "KVM",
 	.detect			= kvm_detect,
 	.type			= X86_HYPER_KVM,
-	.init.init_platform	= kvmclock_init,
 	.init.guest_late_init	= kvm_guest_init,
 	.init.x2apic_available	= kvm_para_available,
 	.init.init_platform	= kvm_init_platform,
-- 
2.18.0

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply related	[flat|nested] 49+ messages in thread

* Re: linux-next: manual merge of the kvm tree with the tip tree
  2018-08-06  5:12 Stephen Rothwell
@ 2018-08-06  6:27 ` Tianyu Lan
  0 siblings, 0 replies; 49+ messages in thread
From: Tianyu Lan @ 2018-08-06  6:27 UTC (permalink / raw)
  To: Stephen Rothwell, Paolo Bonzini, Radim Krčmář,
	KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Vitaly Kuznetsov, Tianyu Lan

Hi Stephen:
	Thanks for fix. I will discuss with maintainer about how to deal with 
the issue.

On 8/6/2018 1:12 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>    arch/x86/include/asm/trace/hyperv.h
> 
> between commit:
> 
>    58ec5e9c9044 ("x86/hyper-v: Trace PV IPI send")
> 
> from the tip tree and commit:
> 
>    47c054685621 ("X86/Hyper-V: Add hyperv_nested_flush_guest_mapping ftrace support")
> 
> 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.
> 

^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2018-08-06  5:12 Stephen Rothwell
  2018-08-06  6:27 ` Tianyu Lan
  0 siblings, 1 reply; 49+ messages in thread
From: Stephen Rothwell @ 2018-08-06  5:12 UTC (permalink / raw)
  To: Paolo Bonzini, Radim Krčmář,
	KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Vitaly Kuznetsov, Tianyu Lan

[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]

Hi all,

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

  arch/x86/include/asm/trace/hyperv.h

between commit:

  58ec5e9c9044 ("x86/hyper-v: Trace PV IPI send")

from the tip tree and commit:

  47c054685621 ("X86/Hyper-V: Add hyperv_nested_flush_guest_mapping ftrace support")

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/include/asm/trace/hyperv.h
index 9c0d4b588e3f,e1ffe61de8d6..000000000000
--- a/arch/x86/include/asm/trace/hyperv.h
+++ b/arch/x86/include/asm/trace/hyperv.h
@@@ -28,21 -28,20 +28,35 @@@ TRACE_EVENT(hyperv_mmu_flush_tlb_others
  		      __entry->addr, __entry->end)
  	);
  
 +TRACE_EVENT(hyperv_send_ipi_mask,
 +	    TP_PROTO(const struct cpumask *cpus,
 +		     int vector),
 +	    TP_ARGS(cpus, vector),
 +	    TP_STRUCT__entry(
 +		    __field(unsigned int, ncpus)
 +		    __field(int, vector)
 +		    ),
 +	    TP_fast_assign(__entry->ncpus = cpumask_weight(cpus);
 +			   __entry->vector = vector;
 +		    ),
 +	    TP_printk("ncpus %d vector %x",
 +		      __entry->ncpus, __entry->vector)
 +	);
 +
+ TRACE_EVENT(hyperv_nested_flush_guest_mapping,
+ 	    TP_PROTO(u64 as, int ret),
+ 	    TP_ARGS(as, ret),
+ 
+ 	    TP_STRUCT__entry(
+ 		    __field(u64, as)
+ 		    __field(int, ret)
+ 		    ),
+ 	    TP_fast_assign(__entry->as = as;
+ 			   __entry->ret = ret;
+ 		    ),
+ 	    TP_printk("address space %llx ret %d", __entry->as, __entry->ret)
+ 	);
+ 
  #endif /* CONFIG_HYPERV */
  
  #undef TRACE_INCLUDE_PATH

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2018-02-02  0:51 Stephen Rothwell
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Rothwell @ 2018-02-02  0:51 UTC (permalink / raw)
  To: Paolo Bonzini, Radim Krčmář,
	KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Dan Williams,
	Jim Mattson

Hi all,

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

  arch/x86/kvm/vmx.c

between commit:

  085331dfc6bb ("x86/kvm: Update spectre-v1 mitigation")

from the tip tree and commit:

  58e9ffae5efd ("kvm: vmx: Reduce size of vmcs_field_to_offset_table")

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/vmx.c
index 28942823cc3a,bb5b4888505b..000000000000
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@@ -899,18 -856,25 +857,22 @@@ static const unsigned short vmcs_field_
  
  static inline short vmcs_field_to_offset(unsigned long field)
  {
 +	const size_t size = ARRAY_SIZE(vmcs_field_to_offset_table);
 +	unsigned short offset;
+ 	unsigned index;
  
- 	BUILD_BUG_ON(size > SHRT_MAX);
- 	if (field >= size)
+ 	if (field >> 15)
  		return -ENOENT;
  
- 	field = array_index_nospec(field, size);
- 	offset = vmcs_field_to_offset_table[field];
+ 	index = ROL16(field, 6);
 -	if (index >= ARRAY_SIZE(vmcs_field_to_offset_table))
++	if (index >= size)
+ 		return -ENOENT;
+ 
 -	/*
 -	 * FIXME: Mitigation for CVE-2017-5753.  To be replaced with a
 -	 * generic mechanism.
 -	 */
 -	asm("lfence");
 -
 -	if (vmcs_field_to_offset_table[index] == 0)
++	index = array_index_nospec(index, size);
++	offset = vmcs_field_to_offset_table[index];
 +	if (offset == 0)
  		return -ENOENT;
 -
 -	return vmcs_field_to_offset_table[index];
 +	return offset;
  }
  
  static inline struct vmcs12 *get_vmcs12(struct kvm_vcpu *vcpu)

^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2018-01-15  2:39 Stephen Rothwell
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Rothwell @ 2018-01-15  2:39 UTC (permalink / raw)
  To: Paolo Bonzini, Radim Krčmář,
	KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	David Woodhouse, Chao Peng, Luwei Kang

Hi all,

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

  arch/x86/kvm/vmx.c

between commit:

  117cc7a908c8 ("x86/retpoline: Fill return stack buffer on vmexit")

from the tip tree and commit:

  3e95fd6d0561 ("KVM: x86: Add Intel Processor Trace virtualization mode")

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/vmx.c
index c829d89e2e63,87ac655760e5..000000000000
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@@ -50,7 -50,7 +50,8 @@@
  #include <asm/apic.h>
  #include <asm/irq_remapping.h>
  #include <asm/mmu_context.h>
 +#include <asm/nospec-branch.h>
+ #include <asm/intel_pt.h>
  
  #include "trace.h"
  #include "pmu.h"
@@@ -9491,12 -9721,9 +9731,12 @@@ static void __noclone vmx_vcpu_run(stru
  #endif
  	      );
  
 +	/* Eliminate branch target predictions from guest mode */
 +	vmexit_fill_RSB();
 +
  	/* MSR_IA32_DEBUGCTLMSR is zeroed on vmexit. Restore it if needed */
- 	if (debugctlmsr)
- 		update_debugctlmsr(debugctlmsr);
+ 	if (vmx->host_debugctlmsr)
+ 		update_debugctlmsr(vmx->host_debugctlmsr);
  
  #ifndef CONFIG_X86_64
  	/*

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: linux-next: manual merge of the kvm tree with the tip tree
  2017-08-28  4:52 Stephen Rothwell
@ 2017-09-04  6:09 ` Stephen Rothwell
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Rothwell @ 2017-09-04  6:09 UTC (permalink / raw)
  To: Marcelo Tosatti, Gleb Natapov, KVM, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Radim Krčmář,
	Brijesh Singh

Hi all,

On Mon, 28 Aug 2017 14:52:09 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>   arch/x86/kvm/mmu.c
> 
> between commit:
> 
>   ea2800ddb20d ("kvm/x86: Avoid clearing the C-bit in rsvd_bits()")
> 
> from the tip tree and commit:
> 
>   d6321d493319 ("KVM: x86: generalize guest_cpuid_has_ helpers")
> 
> 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/mmu.c
> index 04d750813c9d,2a8a6e3e2a31..000000000000
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@@ -4116,21 -4157,11 +4162,21 @@@ reset_shadow_zero_bits_mask(struct kvm_
>   	 * Passing "true" to the last argument is okay; it adds a check
>   	 * on bit 8 of the SPTEs which KVM doesn't use anyway.
>   	 */
>  -	__reset_rsvds_bits_mask(vcpu, &context->shadow_zero_check,
>  +	shadow_zero_check = &context->shadow_zero_check;
>  +	__reset_rsvds_bits_mask(vcpu, shadow_zero_check,
>   				boot_cpu_data.x86_phys_bits,
>   				context->shadow_root_level, uses_nx,
> - 				guest_cpuid_has_gbpages(vcpu), is_pse(vcpu),
> - 				true);
> + 				guest_cpuid_has(vcpu, X86_FEATURE_GBPAGES),
> + 				is_pse(vcpu), true);
>  +
>  +	if (!shadow_me_mask)
>  +		return;
>  +
>  +	for (i = context->shadow_root_level; --i >= 0;) {
>  +		shadow_zero_check->rsvd_bits_mask[0][i] &= ~shadow_me_mask;
>  +		shadow_zero_check->rsvd_bits_mask[1][i] &= ~shadow_me_mask;
>  +	}
>  +
>   }
>   EXPORT_SYMBOL_GPL(reset_shadow_zero_bits_mask);
>   

Just a reminder that this conflict still exists.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2017-08-28  4:52 Stephen Rothwell
  2017-09-04  6:09 ` Stephen Rothwell
  0 siblings, 1 reply; 49+ messages in thread
From: Stephen Rothwell @ 2017-08-28  4:52 UTC (permalink / raw)
  To: Marcelo Tosatti, Gleb Natapov, KVM, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Radim Krčmář,
	Brijesh Singh

Hi all,

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

  arch/x86/kvm/mmu.c

between commit:

  ea2800ddb20d ("kvm/x86: Avoid clearing the C-bit in rsvd_bits()")

from the tip tree and commit:

  d6321d493319 ("KVM: x86: generalize guest_cpuid_has_ helpers")

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/mmu.c
index 04d750813c9d,2a8a6e3e2a31..000000000000
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@@ -4116,21 -4157,11 +4162,21 @@@ reset_shadow_zero_bits_mask(struct kvm_
  	 * Passing "true" to the last argument is okay; it adds a check
  	 * on bit 8 of the SPTEs which KVM doesn't use anyway.
  	 */
 -	__reset_rsvds_bits_mask(vcpu, &context->shadow_zero_check,
 +	shadow_zero_check = &context->shadow_zero_check;
 +	__reset_rsvds_bits_mask(vcpu, shadow_zero_check,
  				boot_cpu_data.x86_phys_bits,
  				context->shadow_root_level, uses_nx,
- 				guest_cpuid_has_gbpages(vcpu), is_pse(vcpu),
- 				true);
+ 				guest_cpuid_has(vcpu, X86_FEATURE_GBPAGES),
+ 				is_pse(vcpu), true);
 +
 +	if (!shadow_me_mask)
 +		return;
 +
 +	for (i = context->shadow_root_level; --i >= 0;) {
 +		shadow_zero_check->rsvd_bits_mask[0][i] &= ~shadow_me_mask;
 +		shadow_zero_check->rsvd_bits_mask[1][i] &= ~shadow_me_mask;
 +	}
 +
  }
  EXPORT_SYMBOL_GPL(reset_shadow_zero_bits_mask);
  

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: linux-next: manual merge of the kvm tree with the tip tree
  2017-08-25 20:42           ` Paolo Bonzini
@ 2017-08-26  7:24             ` Ingo Molnar
  0 siblings, 0 replies; 49+ messages in thread
From: Ingo Molnar @ 2017-08-26  7:24 UTC (permalink / raw)
  To: Paolo Bonzini
  Cc: Brijesh Singh, Tom Lendacky, Stephen Rothwell,
	Radim Krčmář,
	KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux-Next Mailing List,
	Linux Kernel Mailing List, Yu Zhang, paolo.bonzini


* Paolo Bonzini <pbonzini@redhat.com> wrote:

> On 25/08/2017 22:41, Brijesh Singh wrote:
> >>>>
> > 
> >> Neither my version nor yours is correct. :)  The right one has [0][i]
> >> and [1][i] (I inverted the indices by mistake).
> >>
> >> With that change, you can include my
> >>
> >> Acked-by: Paolo Bonzini <pbonzini@redhat.com>
> >>
> > 
> > Ingo,
> > 
> > I assuming that this patch should be sent through the tip since SME support
> > came from tip. I will be submitting the patch very soon.
> 
> Yes, that is correct.  I cannot apply it directly to the KVM tree.

I've merged it to tip:x86/mm where the SME bits live and will propagate it to 
linux-next ASAP, once it's gone through my local testing.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: linux-next: manual merge of the kvm tree with the tip tree
  2017-08-25 20:41         ` Brijesh Singh
@ 2017-08-25 20:42           ` Paolo Bonzini
  2017-08-26  7:24             ` Ingo Molnar
  0 siblings, 1 reply; 49+ messages in thread
From: Paolo Bonzini @ 2017-08-25 20:42 UTC (permalink / raw)
  To: Brijesh Singh, Tom Lendacky, Stephen Rothwell,
	Radim Krčmář,
	KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Yu Zhang,
	paolo.bonzini

On 25/08/2017 22:41, Brijesh Singh wrote:
>>>>
> 
>> Neither my version nor yours is correct. :)  The right one has [0][i]
>> and [1][i] (I inverted the indices by mistake).
>>
>> With that change, you can include my
>>
>> Acked-by: Paolo Bonzini <pbonzini@redhat.com>
>>
> 
> Ingo,
> 
> I assuming that this patch should be sent through the tip since SME support
> came from tip. I will be submitting the patch very soon.

Yes, that is correct.  I cannot apply it directly to the KVM tree.

Paolo

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: linux-next: manual merge of the kvm tree with the tip tree
  2017-08-25 20:05       ` Paolo Bonzini
@ 2017-08-25 20:41         ` Brijesh Singh
  2017-08-25 20:42           ` Paolo Bonzini
  0 siblings, 1 reply; 49+ messages in thread
From: Brijesh Singh @ 2017-08-25 20:41 UTC (permalink / raw)
  To: Paolo Bonzini, Tom Lendacky, Stephen Rothwell,
	Radim Krčmář,
	KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: brijesh.singh, Linux-Next Mailing List,
	Linux Kernel Mailing List, Yu Zhang, paolo.bonzini



On 08/25/2017 03:05 PM, Paolo Bonzini wrote:
> On 25/08/2017 18:53, Brijesh Singh wrote:
>>>

> Neither my version nor yours is correct. :)  The right one has [0][i]
> and [1][i] (I inverted the indices by mistake).
> 
> With that change, you can include my
> 
> Acked-by: Paolo Bonzini <pbonzini@redhat.com>
> 

Ingo,

I assuming that this patch should be sent through the tip since SME support
came from tip. I will be submitting the patch very soon.

-Brijesh

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: linux-next: manual merge of the kvm tree with the tip tree
  2017-08-25 16:53     ` Brijesh Singh
@ 2017-08-25 20:05       ` Paolo Bonzini
  2017-08-25 20:41         ` Brijesh Singh
  0 siblings, 1 reply; 49+ messages in thread
From: Paolo Bonzini @ 2017-08-25 20:05 UTC (permalink / raw)
  To: Brijesh Singh, Tom Lendacky, Stephen Rothwell,
	Radim Krčmář,
	KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Yu Zhang,
	paolo.bonzini

On 25/08/2017 18:53, Brijesh Singh wrote:
>>
> 
> Thanks for the tip, I have expanded the patch to cover tdp cases and
> have verified
> that it works fine with SME enabled KVM. If you are okay with this then
> I can
> send patch.
> 
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index ccb70b8..7a8edc0 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -4109,16 +4109,30 @@ void
>  reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu
> *context)
>  {
>         bool uses_nx = context->nx || context->base_role.smep_andnot_wp;
> +       struct rsvd_bits_validate *shadow_zero_check;
> +       int i;
>  
>         /*
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index ccb70b8..7a8edc0 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -4109,16 +4109,30 @@ void
>  reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu
> *context)
>  {
>         bool uses_nx = context->nx || context->base_role.smep_andnot_wp;
> +       struct rsvd_bits_validate *shadow_zero_check;
> +       int i;
>  
>         /*
>          * Passing "true" to the last argument is okay; it adds a check
>          * on bit 8 of the SPTEs which KVM doesn't use anyway.
>          */
> -       __reset_rsvds_bits_mask(vcpu, &context->shadow_zero_check,
> +       shadow_zero_check = &context->shadow_zero_check;
> +       __reset_rsvds_bits_mask(vcpu, shadow_zero_check,
>                                 boot_cpu_data.x86_phys_bits,
>                                 context->shadow_root_level, uses_nx,
>                                 guest_cpuid_has_gbpages(vcpu),
> is_pse(vcpu),
>                                 true);
> +
> +       if (!shadow_me_mask)
> +               return;
> +
> +       for (i = context->shadow_root_level; --i >= 0;) {
> +               shadow_zero_check->rsvd_bits_mask[i][0] &= ~shadow_me_mask;
> +               shadow_zero_check->rsvd_bits_mask[i][1] &= ~shadow_me_mask;
> +               shadow_zero_check->rsvd_bits_mask[i][2] &= ~shadow_me_mask;
> +               shadow_zero_check->rsvd_bits_mask[i][3] &= ~shadow_me_mask;

Neither my version nor yours is correct. :)  The right one has [0][i]
and [1][i] (I inverted the indices by mistake).

With that change, you can include my

Acked-by: Paolo Bonzini <pbonzini@redhat.com>

> +       }
> +
>  }
>  EXPORT_SYMBOL_GPL(reset_shadow_zero_bits_mask);
>  
> @@ -4136,8 +4150,13 @@ static void
>  reset_tdp_shadow_zero_bits_mask(struct kvm_vcpu *vcpu,
>                                 struct kvm_mmu *context)
>  {
> +       struct rsvd_bits_validate *shadow_zero_check;
> +       int i;
> +
> +       shadow_zero_check = &context->shadow_zero_check;
> +
>         if (boot_cpu_is_amd())
> -               __reset_rsvds_bits_mask(vcpu, &context->shadow_zero_check,
> +               __reset_rsvds_bits_mask(vcpu, shadow_zero_check,
>                                         boot_cpu_data.x86_phys_bits,
>                                         context->shadow_root_level, false,
>                                         boot_cpu_has(X86_FEATURE_GBPAGES),

Please use shadow_zero_check here too:

                __reset_rsvds_bits_mask_ept(&context->shadow_zero_check,

Thanks,

Paolo

> @@ -4147,6 +4166,15 @@ reset_tdp_shadow_zero_bits_mask(struct kvm_vcpu
> *vcpu,
>                                             boot_cpu_data.x86_phys_bits,
>                                             false);
>  
> +       if (!shadow_me_mask)
> +               return;
> +
> +       for (i = context->shadow_root_level; --i >= 0;) {
> +               shadow_zero_check->rsvd_bits_mask[i][0] &= ~shadow_me_mask;
> +               shadow_zero_check->rsvd_bits_mask[i][1] &= ~shadow_me_mask;
> +               shadow_zero_check->rsvd_bits_mask[i][2] &= ~shadow_me_mask;
> +               shadow_zero_check->rsvd_bits_mask[i][3] &= ~shadow_me_mask;
> +       }
>  }
>  
>  /*
> diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
> index 3cc7255..d7d248a 100644
> --- a/arch/x86/kvm/mmu.h
> +++ b/arch/x86/kvm/mmu.h
> @@ -48,7 +48,7 @@
>  
>  static inline u64 rsvd_bits(int s, int e)
>  {
> -       return __sme_clr(((1ULL << (e - s + 1)) - 1) << s);
> +       return ((1ULL << (e - s + 1)) - 1) << s;
>  }
>  
>  void kvm_mmu_set_mmio_spte_mask(u64 mmio_mask, u64 mmio_value);
> 
> 

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: linux-next: manual merge of the kvm tree with the tip tree
  2017-08-25 13:57   ` Tom Lendacky
@ 2017-08-25 16:53     ` Brijesh Singh
  2017-08-25 20:05       ` Paolo Bonzini
  0 siblings, 1 reply; 49+ messages in thread
From: Brijesh Singh @ 2017-08-25 16:53 UTC (permalink / raw)
  To: Tom Lendacky, Paolo Bonzini, Stephen Rothwell,
	Radim Krčmář,
	KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: brijesh.singh, Linux-Next Mailing List,
	Linux Kernel Mailing List, Yu Zhang, paolo.bonzini

Hi Paolo,


On 08/25/2017 08:57 AM, Tom Lendacky wrote:
> On 8/25/2017 1:39 AM, Paolo Bonzini wrote:
>> On 25/08/2017 06:39, Stephen Rothwell wrote:

>> First, rsvd_bits is just a simple function to return some 1 bits.  Applying
>> a mask based on properties of the host MMU is incorrect.
>>
>> Second, the masks computed by __reset_rsvds_bits_mask also apply to
>> guest page tables, where the C bit is reserved since we don't emulate
>> SME.
>>
>> Something like this:
> 

Thanks for the tip, I have expanded the patch to cover tdp cases and have verified
that it works fine with SME enabled KVM. If you are okay with this then I can
send patch.

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index ccb70b8..7a8edc0 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4109,16 +4109,30 @@ void
  reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu *context)
  {
         bool uses_nx = context->nx || context->base_role.smep_andnot_wp;
+       struct rsvd_bits_validate *shadow_zero_check;
+       int i;
  
         /*
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index ccb70b8..7a8edc0 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4109,16 +4109,30 @@ void
  reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu *context)
  {
         bool uses_nx = context->nx || context->base_role.smep_andnot_wp;
+       struct rsvd_bits_validate *shadow_zero_check;
+       int i;
  
         /*
          * Passing "true" to the last argument is okay; it adds a check
          * on bit 8 of the SPTEs which KVM doesn't use anyway.
          */
-       __reset_rsvds_bits_mask(vcpu, &context->shadow_zero_check,
+       shadow_zero_check = &context->shadow_zero_check;
+       __reset_rsvds_bits_mask(vcpu, shadow_zero_check,
                                 boot_cpu_data.x86_phys_bits,
                                 context->shadow_root_level, uses_nx,
                                 guest_cpuid_has_gbpages(vcpu), is_pse(vcpu),
                                 true);
+
+       if (!shadow_me_mask)
+               return;
+
+       for (i = context->shadow_root_level; --i >= 0;) {
+               shadow_zero_check->rsvd_bits_mask[i][0] &= ~shadow_me_mask;
+               shadow_zero_check->rsvd_bits_mask[i][1] &= ~shadow_me_mask;
+               shadow_zero_check->rsvd_bits_mask[i][2] &= ~shadow_me_mask;
+               shadow_zero_check->rsvd_bits_mask[i][3] &= ~shadow_me_mask;
+       }
+
  }
  EXPORT_SYMBOL_GPL(reset_shadow_zero_bits_mask);
  
@@ -4136,8 +4150,13 @@ static void
  reset_tdp_shadow_zero_bits_mask(struct kvm_vcpu *vcpu,
                                 struct kvm_mmu *context)
  {
+       struct rsvd_bits_validate *shadow_zero_check;
+       int i;
+
+       shadow_zero_check = &context->shadow_zero_check;
+
         if (boot_cpu_is_amd())
-               __reset_rsvds_bits_mask(vcpu, &context->shadow_zero_check,
+               __reset_rsvds_bits_mask(vcpu, shadow_zero_check,
                                         boot_cpu_data.x86_phys_bits,
                                         context->shadow_root_level, false,
                                         boot_cpu_has(X86_FEATURE_GBPAGES),
@@ -4147,6 +4166,15 @@ reset_tdp_shadow_zero_bits_mask(struct kvm_vcpu *vcpu,
                                             boot_cpu_data.x86_phys_bits,
                                             false);
  
+       if (!shadow_me_mask)
+               return;
+
+       for (i = context->shadow_root_level; --i >= 0;) {
+               shadow_zero_check->rsvd_bits_mask[i][0] &= ~shadow_me_mask;
+               shadow_zero_check->rsvd_bits_mask[i][1] &= ~shadow_me_mask;
+               shadow_zero_check->rsvd_bits_mask[i][2] &= ~shadow_me_mask;
+               shadow_zero_check->rsvd_bits_mask[i][3] &= ~shadow_me_mask;
+       }
  }
  
  /*
diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
index 3cc7255..d7d248a 100644
--- a/arch/x86/kvm/mmu.h
+++ b/arch/x86/kvm/mmu.h
@@ -48,7 +48,7 @@
  
  static inline u64 rsvd_bits(int s, int e)
  {
-       return __sme_clr(((1ULL << (e - s + 1)) - 1) << s);
+       return ((1ULL << (e - s + 1)) - 1) << s;
  }
  
  void kvm_mmu_set_mmio_spte_mask(u64 mmio_mask, u64 mmio_value);





> Thanks Paolo, Brijesh and I will test this and make sure everything works
> properly with this patch.
> 
> Thanks,
> Tom
> 
>>
>> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
>> index 2dafd36368cc..e0597d703d72 100644
>> --- a/arch/x86/kvm/mmu.c
>> +++ b/arch/x86/kvm/mmu.c
>> @@ -4142,16 +4142,24 @@ void
>>   reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu *context)
>>   {
>>       bool uses_nx = context->nx || context->base_role.smep_andnot_wp;
>> +    struct rsvd_bits_validate *shadow_zero_check;
>> +    int i;
>>       /*
>>        * Passing "true" to the last argument is okay; it adds a check
>>        * on bit 8 of the SPTEs which KVM doesn't use anyway.
>>        */
>> -    __reset_rsvds_bits_mask(vcpu, &context->shadow_zero_check,
>> +        shadow_zero_check = &context->shadow_zero_check;
>> +    __reset_rsvds_bits_mask(vcpu, shadow_zero_check,
>>                   boot_cpu_data.x86_phys_bits,
>>                   context->shadow_root_level, uses_nx,
>>                   guest_cpuid_has(vcpu, X86_FEATURE_GBPAGES),
>>                   is_pse(vcpu), true);
>> +
>> +    for (i = context->shadow_root_level; --i >= 0; ) {
>> +        shadow_zero_check->rsvd_bits_mask[i][0] &= ~shadow_me_mask;
>> +        shadow_zero_check->rsvd_bits_mask[i][1] &= ~shadow_me_mask;
>> +    }
>>   }
>>   EXPORT_SYMBOL_GPL(reset_shadow_zero_bits_mask);
>>
>> Can you please fix it up?   Please Cc me at paolo.bonzini@gmail.com too
>> because I'll be on vacation next week.
>>
>> (And thanks Stephen for the heads-up!)
>>
>> Paolo
>>

^ permalink raw reply related	[flat|nested] 49+ messages in thread

* Re: linux-next: manual merge of the kvm tree with the tip tree
  2017-08-25  6:39 ` Paolo Bonzini
@ 2017-08-25 13:57   ` Tom Lendacky
  2017-08-25 16:53     ` Brijesh Singh
  0 siblings, 1 reply; 49+ messages in thread
From: Tom Lendacky @ 2017-08-25 13:57 UTC (permalink / raw)
  To: Paolo Bonzini, Stephen Rothwell, Radim Krčmář,
	KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Yu Zhang,
	Brijesh Singh

On 8/25/2017 1:39 AM, Paolo Bonzini wrote:
> On 25/08/2017 06:39, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the kvm tree got a conflict in:
>>
>>    arch/x86/kvm/mmu.h
>>
>> between commit:
>>
>>    d0ec49d4de90 ("kvm/x86/svm: Support Secure Memory Encryption within KVM")
>>
>> from the tip tree and commit:
>>
>>    d1cd3ce90044 ("KVM: MMU: check guest CR3 reserved bits based on its physical address width.")
>>
>> 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.
>>
> 
> Thomas L., Ingo,
> 
> this is completely wrong:
> 
>>
>>   static inline u64 rsvd_bits(int s, int e)
>>   {
>> -	return ((1ULL << (e - s + 1)) - 1) << s;
>> +	return __sme_clr(((1ULL << (e - s + 1)) - 1) << s);
>>   }
>>   
> 
> First, rsvd_bits is just a simple function to return some 1 bits.  Applying
> a mask based on properties of the host MMU is incorrect.
> 
> Second, the masks computed by __reset_rsvds_bits_mask also apply to
> guest page tables, where the C bit is reserved since we don't emulate
> SME.
> 
> Something like this:

Thanks Paolo, Brijesh and I will test this and make sure everything works
properly with this patch.

Thanks,
Tom

> 
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index 2dafd36368cc..e0597d703d72 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -4142,16 +4142,24 @@ void
>   reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu *context)
>   {
>   	bool uses_nx = context->nx || context->base_role.smep_andnot_wp;
> +	struct rsvd_bits_validate *shadow_zero_check;
> +	int i;
>   
>   	/*
>   	 * Passing "true" to the last argument is okay; it adds a check
>   	 * on bit 8 of the SPTEs which KVM doesn't use anyway.
>   	 */
> -	__reset_rsvds_bits_mask(vcpu, &context->shadow_zero_check,
> +        shadow_zero_check = &context->shadow_zero_check;
> +	__reset_rsvds_bits_mask(vcpu, shadow_zero_check,
>   				boot_cpu_data.x86_phys_bits,
>   				context->shadow_root_level, uses_nx,
>   				guest_cpuid_has(vcpu, X86_FEATURE_GBPAGES),
>   				is_pse(vcpu), true);
> +
> +	for (i = context->shadow_root_level; --i >= 0; ) {
> +		shadow_zero_check->rsvd_bits_mask[i][0] &= ~shadow_me_mask;
> +		shadow_zero_check->rsvd_bits_mask[i][1] &= ~shadow_me_mask;
> +	}
>   }
>   EXPORT_SYMBOL_GPL(reset_shadow_zero_bits_mask);
>   
> 
> Can you please fix it up?   Please Cc me at paolo.bonzini@gmail.com too
> because I'll be on vacation next week.
> 
> (And thanks Stephen for the heads-up!)
> 
> Paolo
> 

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: linux-next: manual merge of the kvm tree with the tip tree
  2017-08-25  4:39 Stephen Rothwell
@ 2017-08-25  6:39 ` Paolo Bonzini
  2017-08-25 13:57   ` Tom Lendacky
  0 siblings, 1 reply; 49+ messages in thread
From: Paolo Bonzini @ 2017-08-25  6:39 UTC (permalink / raw)
  To: Stephen Rothwell, Radim Krčmář,
	KVM, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Tom Lendacky,
	Yu Zhang, Brijesh Singh

On 25/08/2017 06:39, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>   arch/x86/kvm/mmu.h
> 
> between commit:
> 
>   d0ec49d4de90 ("kvm/x86/svm: Support Secure Memory Encryption within KVM")
> 
> from the tip tree and commit:
> 
>   d1cd3ce90044 ("KVM: MMU: check guest CR3 reserved bits based on its physical address width.")
> 
> 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.
> 

Thomas L., Ingo,

this is completely wrong:

> 
>  static inline u64 rsvd_bits(int s, int e)
>  {
> -	return ((1ULL << (e - s + 1)) - 1) << s;
> +	return __sme_clr(((1ULL << (e - s + 1)) - 1) << s);
>  }
>  

First, rsvd_bits is just a simple function to return some 1 bits.  Applying
a mask based on properties of the host MMU is incorrect.

Second, the masks computed by __reset_rsvds_bits_mask also apply to 
guest page tables, where the C bit is reserved since we don't emulate
SME.

Something like this:

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 2dafd36368cc..e0597d703d72 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4142,16 +4142,24 @@ void
 reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu *context)
 {
 	bool uses_nx = context->nx || context->base_role.smep_andnot_wp;
+	struct rsvd_bits_validate *shadow_zero_check;
+	int i;
 
 	/*
 	 * Passing "true" to the last argument is okay; it adds a check
 	 * on bit 8 of the SPTEs which KVM doesn't use anyway.
 	 */
-	__reset_rsvds_bits_mask(vcpu, &context->shadow_zero_check,
+        shadow_zero_check = &context->shadow_zero_check;
+	__reset_rsvds_bits_mask(vcpu, shadow_zero_check,
 				boot_cpu_data.x86_phys_bits,
 				context->shadow_root_level, uses_nx,
 				guest_cpuid_has(vcpu, X86_FEATURE_GBPAGES),
 				is_pse(vcpu), true);
+
+	for (i = context->shadow_root_level; --i >= 0; ) {
+		shadow_zero_check->rsvd_bits_mask[i][0] &= ~shadow_me_mask;
+		shadow_zero_check->rsvd_bits_mask[i][1] &= ~shadow_me_mask;
+	}
 }
 EXPORT_SYMBOL_GPL(reset_shadow_zero_bits_mask);
 

Can you please fix it up?   Please Cc me at paolo.bonzini@gmail.com too 
because I'll be on vacation next week.

(And thanks Stephen for the heads-up!)

Paolo

^ permalink raw reply related	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2017-08-25  4:39 Stephen Rothwell
  2017-08-25  6:39 ` Paolo Bonzini
  0 siblings, 1 reply; 49+ messages in thread
From: Stephen Rothwell @ 2017-08-25  4:39 UTC (permalink / raw)
  To: Marcelo Tosatti, Gleb Natapov, KVM, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Tom Lendacky,
	Yu Zhang, Paolo Bonzini

Hi all,

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

  arch/x86/kvm/mmu.h

between commit:

  d0ec49d4de90 ("kvm/x86/svm: Support Secure Memory Encryption within KVM")

from the tip tree and commit:

  d1cd3ce90044 ("KVM: MMU: check guest CR3 reserved bits based on its physical address width.")

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/mmu.h
index 3cc725590ab9,e2999f57bfc4..000000000000
--- a/arch/x86/kvm/mmu.h
+++ b/arch/x86/kvm/mmu.h
@@@ -48,7 -49,10 +49,10 @@@
  
  static inline u64 rsvd_bits(int s, int e)
  {
+ 	if (e < s)
+ 		return 0;
+ 
 -	return ((1ULL << (e - s + 1)) - 1) << s;
 +	return __sme_clr(((1ULL << (e - s + 1)) - 1) << s);
  }
  
  void kvm_mmu_set_mmio_spte_mask(u64 mmio_mask, u64 mmio_value);

^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2016-11-28  3:56 Stephen Rothwell
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Rothwell @ 2016-11-28  3:56 UTC (permalink / raw)
  To: Marcelo Tosatti, Gleb Natapov, KVM, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Andy Lutomirski, Luwei Kang,
	Radim Krčmář

Hi all,

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

  arch/x86/kvm/cpuid.c

between commit:

  c592b5734706 ("x86/fpu: Remove use_eager_fpu()")

from the tip tree and commit:

  4504b5c9414c ("kvm: x86: Add AVX512_4VNNIW and AVX512_4FMAPS support")

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/cpuid.c
index 0aefb626fa8f,25f0f15fab1a..000000000000
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@@ -16,6 -16,8 +16,7 @@@
  #include <linux/export.h>
  #include <linux/vmalloc.h>
  #include <linux/uaccess.h>
+ #include <asm/processor.h>
 -#include <asm/fpu/internal.h> /* For use_eager_fpu.  Ugh! */
  #include <asm/user.h>
  #include <asm/fpu/xstate.h>
  #include "cpuid.h"

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: linux-next: manual merge of the kvm tree with the tip tree
  2016-11-17  7:07 ` Thomas Gleixner
@ 2016-11-17 21:31   ` Stephen Rothwell
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Rothwell @ 2016-11-17 21:31 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Marcelo Tosatti, Gleb Natapov, KVM, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Fenghua Yu, He Chen

Hi Thomas,

On Thu, 17 Nov 2016 08:07:27 +0100 (CET) Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Thu, 17 Nov 2016, Stephen Rothwell wrote:
> > + /* Please keep the leaf sorted by cpuid_bit.level for faster search. */
> > + static const struct cpuid_bit cpuid_bits[] = {
> > + 	{ X86_FEATURE_APERFMPERF,       CPUID_ECX,  0, 0x00000006, 0 },
> > + 	{ X86_FEATURE_EPB,              CPUID_ECX,  3, 0x00000006, 0 },
> > ++	{ X86_FEATURE_CAT_L3,		CPUID_EBX,  1, 0x00000010, 0 },
> > ++	{ X86_FEATURE_CAT_L2,		CPUID_EBX,  2, 0x00000010, 0 },
> > ++	{ X86_FEATURE_CDP_L3,		CPUID_ECX,  2, 0x00000010, 1 },
> > + 	{ X86_FEATURE_INTEL_PT,         CPUID_EBX, 25, 0x00000007, 0 },
> > + 	{ X86_FEATURE_AVX512_4VNNIW,    CPUID_EDX,  2, 0x00000007, 0 },
> > + 	{ X86_FEATURE_AVX512_4FMAPS,    CPUID_EDX,  3, 0x00000007, 0 },
> > + 	{ X86_FEATURE_HW_PSTATE,        CPUID_EDX,  7, 0x80000007, 0 },
> > + 	{ X86_FEATURE_CPB,              CPUID_EDX,  9, 0x80000007, 0 },
> > + 	{ X86_FEATURE_PROC_FEEDBACK,    CPUID_EDX, 11, 0x80000007, 0 },
> > + 	{ 0, 0, 0, 0, 0 }
> >   };  
> 
> This should be
> 
> > + static const struct cpuid_bit cpuid_bits[] = {
> > + 	{ X86_FEATURE_APERFMPERF,       CPUID_ECX,  0, 0x00000006, 0 },
> > + 	{ X86_FEATURE_EPB,              CPUID_ECX,  3, 0x00000006, 0 },
> > + 	{ X86_FEATURE_INTEL_PT,         CPUID_EBX, 25, 0x00000007, 0 },
> > + 	{ X86_FEATURE_AVX512_4VNNIW,    CPUID_EDX,  2, 0x00000007, 0 },
> > + 	{ X86_FEATURE_AVX512_4FMAPS,    CPUID_EDX,  3, 0x00000007, 0 },
> > ++	{ X86_FEATURE_CAT_L3,		CPUID_EBX,  1, 0x00000010, 0 },
> > ++	{ X86_FEATURE_CAT_L2,		CPUID_EBX,  2, 0x00000010, 0 },
> > ++	{ X86_FEATURE_CDP_L3,		CPUID_ECX,  2, 0x00000010, 1 },
> > + 	{ X86_FEATURE_HW_PSTATE,        CPUID_EDX,  7, 0x80000007, 0 },
> > + 	{ X86_FEATURE_CPB,              CPUID_EDX,  9, 0x80000007, 0 },
> > + 	{ X86_FEATURE_PROC_FEEDBACK,    CPUID_EDX, 11, 0x80000007, 0 },
> > + 	{ 0, 0, 0, 0, 0 }
> >   };  

Thanks for letting me know.

> tip will carry a proper resolution today.

Too easy.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: linux-next: manual merge of the kvm tree with the tip tree
  2016-11-17  3:50 Stephen Rothwell
@ 2016-11-17  7:07 ` Thomas Gleixner
  2016-11-17 21:31   ` Stephen Rothwell
  0 siblings, 1 reply; 49+ messages in thread
From: Thomas Gleixner @ 2016-11-17  7:07 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Marcelo Tosatti, Gleb Natapov, KVM, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Fenghua Yu, He Chen

On Thu, 17 Nov 2016, Stephen Rothwell wrote:
> + /* Please keep the leaf sorted by cpuid_bit.level for faster search. */
> + static const struct cpuid_bit cpuid_bits[] = {
> + 	{ X86_FEATURE_APERFMPERF,       CPUID_ECX,  0, 0x00000006, 0 },
> + 	{ X86_FEATURE_EPB,              CPUID_ECX,  3, 0x00000006, 0 },
> ++	{ X86_FEATURE_CAT_L3,		CPUID_EBX,  1, 0x00000010, 0 },
> ++	{ X86_FEATURE_CAT_L2,		CPUID_EBX,  2, 0x00000010, 0 },
> ++	{ X86_FEATURE_CDP_L3,		CPUID_ECX,  2, 0x00000010, 1 },
> + 	{ X86_FEATURE_INTEL_PT,         CPUID_EBX, 25, 0x00000007, 0 },
> + 	{ X86_FEATURE_AVX512_4VNNIW,    CPUID_EDX,  2, 0x00000007, 0 },
> + 	{ X86_FEATURE_AVX512_4FMAPS,    CPUID_EDX,  3, 0x00000007, 0 },
> + 	{ X86_FEATURE_HW_PSTATE,        CPUID_EDX,  7, 0x80000007, 0 },
> + 	{ X86_FEATURE_CPB,              CPUID_EDX,  9, 0x80000007, 0 },
> + 	{ X86_FEATURE_PROC_FEEDBACK,    CPUID_EDX, 11, 0x80000007, 0 },
> + 	{ 0, 0, 0, 0, 0 }
>   };

This should be

> + static const struct cpuid_bit cpuid_bits[] = {
> + 	{ X86_FEATURE_APERFMPERF,       CPUID_ECX,  0, 0x00000006, 0 },
> + 	{ X86_FEATURE_EPB,              CPUID_ECX,  3, 0x00000006, 0 },
> + 	{ X86_FEATURE_INTEL_PT,         CPUID_EBX, 25, 0x00000007, 0 },
> + 	{ X86_FEATURE_AVX512_4VNNIW,    CPUID_EDX,  2, 0x00000007, 0 },
> + 	{ X86_FEATURE_AVX512_4FMAPS,    CPUID_EDX,  3, 0x00000007, 0 },
> ++	{ X86_FEATURE_CAT_L3,		CPUID_EBX,  1, 0x00000010, 0 },
> ++	{ X86_FEATURE_CAT_L2,		CPUID_EBX,  2, 0x00000010, 0 },
> ++	{ X86_FEATURE_CDP_L3,		CPUID_ECX,  2, 0x00000010, 1 },
> + 	{ X86_FEATURE_HW_PSTATE,        CPUID_EDX,  7, 0x80000007, 0 },
> + 	{ X86_FEATURE_CPB,              CPUID_EDX,  9, 0x80000007, 0 },
> + 	{ X86_FEATURE_PROC_FEEDBACK,    CPUID_EDX, 11, 0x80000007, 0 },
> + 	{ 0, 0, 0, 0, 0 }
>   };

tip will carry a proper resolution today.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2016-11-17  3:50 Stephen Rothwell
  2016-11-17  7:07 ` Thomas Gleixner
  0 siblings, 1 reply; 49+ messages in thread
From: Stephen Rothwell @ 2016-11-17  3:50 UTC (permalink / raw)
  To: Marcelo Tosatti, Gleb Natapov, KVM, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Fenghua Yu, He Chen

Hi all,

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

  arch/x86/kernel/cpu/scattered.c

between commit:

  4ab1586488cb ("x86/cpufeature: Add RDT CPUID feature bits")

from the tip tree and commits:

  47f10a36003e ("x86/cpuid: Cleanup cpuid_regs definitions")
  47bdf3378d62 ("x86/cpuid: Provide get_scattered_cpuid_leaf()")

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/kernel/cpu/scattered.c
index 49fb680bb0e5,d1316f9c8329..000000000000
--- a/arch/x86/kernel/cpu/scattered.c
+++ b/arch/x86/kernel/cpu/scattered.c
@@@ -17,11 -17,17 +17,20 @@@ struct cpuid_bit 
  	u32 sub_leaf;
  };
  
- enum cpuid_regs {
- 	CR_EAX = 0,
- 	CR_ECX,
- 	CR_EDX,
- 	CR_EBX
+ /* Please keep the leaf sorted by cpuid_bit.level for faster search. */
+ static const struct cpuid_bit cpuid_bits[] = {
+ 	{ X86_FEATURE_APERFMPERF,       CPUID_ECX,  0, 0x00000006, 0 },
+ 	{ X86_FEATURE_EPB,              CPUID_ECX,  3, 0x00000006, 0 },
++	{ X86_FEATURE_CAT_L3,		CPUID_EBX,  1, 0x00000010, 0 },
++	{ X86_FEATURE_CAT_L2,		CPUID_EBX,  2, 0x00000010, 0 },
++	{ X86_FEATURE_CDP_L3,		CPUID_ECX,  2, 0x00000010, 1 },
+ 	{ X86_FEATURE_INTEL_PT,         CPUID_EBX, 25, 0x00000007, 0 },
+ 	{ X86_FEATURE_AVX512_4VNNIW,    CPUID_EDX,  2, 0x00000007, 0 },
+ 	{ X86_FEATURE_AVX512_4FMAPS,    CPUID_EDX,  3, 0x00000007, 0 },
+ 	{ X86_FEATURE_HW_PSTATE,        CPUID_EDX,  7, 0x80000007, 0 },
+ 	{ X86_FEATURE_CPB,              CPUID_EDX,  9, 0x80000007, 0 },
+ 	{ X86_FEATURE_PROC_FEEDBACK,    CPUID_EDX, 11, 0x80000007, 0 },
+ 	{ 0, 0, 0, 0, 0 }
  };
  
  void init_scattered_cpuid_features(struct cpuinfo_x86 *c)

^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2016-05-12  2:54 ` Stephen Rothwell
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Rothwell @ 2016-05-12  2:54 UTC (permalink / raw)
  To: Marcelo Tosatti, Gleb Natapov, kvm
  Cc: linux-next, linux-kernel, Julien Grall, Christoffer Dall,
	Jon Hunter, Marc Zyngier

Hi all,

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

  drivers/irqchip/irq-gic.c

between commits:

  dc9722cc57eb ("irqchip/gic: Return an error if GIC initialisation fails")
  f673b9b5cb54 ("irqchip/gic: Store GIC configuration parameters")
  d6490461a102 ("irqchip/gic: Add helper functions for GIC setup and teardown")

from the tip tree and commits:

  bafa9193d00c ("irqchip/gic-v2: Gather ACPI specific data in a single structure")
  502d6df11ae3 ("irqchip/gic-v2: Parse and export virtual GIC information")

from the kvm tree.

I fixed it up (hopefully - 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 drivers/irqchip/irq-gic.c
index 1de20e14a721,3f1d9fd3a462..000000000000
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@@ -1248,30 -1191,29 +1250,53 @@@ static bool gic_check_eoimode(struct de
  	return true;
  }
  
 +static int gic_of_setup(struct gic_chip_data *gic, struct device_node *node)
 +{
 +	if (!gic || !node)
 +		return -EINVAL;
 +
 +	gic->raw_dist_base = of_iomap(node, 0);
 +	if (WARN(!gic->raw_dist_base, "unable to map gic dist registers\n"))
 +		goto error;
 +
 +	gic->raw_cpu_base = of_iomap(node, 1);
 +	if (WARN(!gic->raw_cpu_base, "unable to map gic cpu registers\n"))
 +		goto error;
 +
 +	if (of_property_read_u32(node, "cpu-offset", &gic->percpu_offset))
 +		gic->percpu_offset = 0;
 +
 +	return 0;
 +
 +error:
 +	gic_teardown(gic);
 +
 +	return -ENOMEM;
 +}
 +
+ static void __init gic_of_setup_kvm_info(struct device_node *node)
+ {
+ 	int ret;
+ 	struct resource *vctrl_res = &gic_v2_kvm_info.vctrl;
+ 	struct resource *vcpu_res = &gic_v2_kvm_info.vcpu;
+ 
+ 	gic_v2_kvm_info.type = GIC_V2;
+ 
+ 	gic_v2_kvm_info.maint_irq = irq_of_parse_and_map(node, 0);
+ 	if (!gic_v2_kvm_info.maint_irq)
+ 		return;
+ 
+ 	ret = of_address_to_resource(node, 2, vctrl_res);
+ 	if (ret)
+ 		return;
+ 
+ 	ret = of_address_to_resource(node, 3, vcpu_res);
+ 	if (ret)
+ 		return;
+ 
+ 	gic_set_kvm_info(&gic_v2_kvm_info);
+ }
+ 
  int __init
  gic_of_init(struct device_node *node, struct device_node *parent)
  {
@@@ -1294,17 -1235,18 +1319,19 @@@
  	 * Disable split EOI/Deactivate if either HYP is not available
  	 * or the CPU interface is too small.
  	 */
 -	if (gic_cnt == 0 && !gic_check_eoimode(node, &cpu_base))
 +	if (gic_cnt == 0 && !gic_check_eoimode(node, &gic->raw_cpu_base))
  		static_key_slow_dec(&supports_deactivate);
  
 -	if (of_property_read_u32(node, "cpu-offset", &percpu_offset))
 -		percpu_offset = 0;
 +	ret = __gic_init_bases(gic, -1, &node->fwnode);
 +	if (ret) {
 +		gic_teardown(gic);
 +		return ret;
 +	}
  
- 	if (!gic_cnt)
 -	__gic_init_bases(gic_cnt, -1, dist_base, cpu_base, percpu_offset,
 -			 &node->fwnode);
+ 	if (!gic_cnt) {
  		gic_init_physaddr(node);
+ 		gic_of_setup_kvm_info(node);
+ 	}
  
  	if (parent) {
  		irq = irq_of_parse_and_map(node, 0);
@@@ -1401,8 -1391,8 +1476,8 @@@ static int __init gic_v2_acpi_init(stru
  		return -EINVAL;
  	}
  
- 	gic->raw_cpu_base = ioremap(cpu_phy_base, ACPI_GIC_CPU_IF_MEM_SIZE);
 -	cpu_base = ioremap(acpi_data.cpu_phys_base, ACPI_GIC_CPU_IF_MEM_SIZE);
 -	if (!cpu_base) {
++	gic->raw_cpu_base = ioremap(acpi_data.cpu_phys_base, ACPI_GIC_CPU_IF_MEM_SIZE);
 +	if (!gic->raw_cpu_base) {
  		pr_err("Unable to map GICC registers\n");
  		return -ENOMEM;
  	}

^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2016-05-12  2:54 ` Stephen Rothwell
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Rothwell @ 2016-05-12  2:54 UTC (permalink / raw)
  To: Marcelo Tosatti, Gleb Natapov, kvm
  Cc: linux-next, linux-kernel, Julien Grall, Christoffer Dall,
	Jon Hunter, Marc Zyngier

Hi all,

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

  drivers/irqchip/irq-gic.c

between commits:

  dc9722cc57eb ("irqchip/gic: Return an error if GIC initialisation fails")
  f673b9b5cb54 ("irqchip/gic: Store GIC configuration parameters")
  d6490461a102 ("irqchip/gic: Add helper functions for GIC setup and teardown")

from the tip tree and commits:

  bafa9193d00c ("irqchip/gic-v2: Gather ACPI specific data in a single structure")
  502d6df11ae3 ("irqchip/gic-v2: Parse and export virtual GIC information")

from the kvm tree.

I fixed it up (hopefully - 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 drivers/irqchip/irq-gic.c
index 1de20e14a721,3f1d9fd3a462..000000000000
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@@ -1248,30 -1191,29 +1250,53 @@@ static bool gic_check_eoimode(struct de
  	return true;
  }
  
 +static int gic_of_setup(struct gic_chip_data *gic, struct device_node *node)
 +{
 +	if (!gic || !node)
 +		return -EINVAL;
 +
 +	gic->raw_dist_base = of_iomap(node, 0);
 +	if (WARN(!gic->raw_dist_base, "unable to map gic dist registers\n"))
 +		goto error;
 +
 +	gic->raw_cpu_base = of_iomap(node, 1);
 +	if (WARN(!gic->raw_cpu_base, "unable to map gic cpu registers\n"))
 +		goto error;
 +
 +	if (of_property_read_u32(node, "cpu-offset", &gic->percpu_offset))
 +		gic->percpu_offset = 0;
 +
 +	return 0;
 +
 +error:
 +	gic_teardown(gic);
 +
 +	return -ENOMEM;
 +}
 +
+ static void __init gic_of_setup_kvm_info(struct device_node *node)
+ {
+ 	int ret;
+ 	struct resource *vctrl_res = &gic_v2_kvm_info.vctrl;
+ 	struct resource *vcpu_res = &gic_v2_kvm_info.vcpu;
+ 
+ 	gic_v2_kvm_info.type = GIC_V2;
+ 
+ 	gic_v2_kvm_info.maint_irq = irq_of_parse_and_map(node, 0);
+ 	if (!gic_v2_kvm_info.maint_irq)
+ 		return;
+ 
+ 	ret = of_address_to_resource(node, 2, vctrl_res);
+ 	if (ret)
+ 		return;
+ 
+ 	ret = of_address_to_resource(node, 3, vcpu_res);
+ 	if (ret)
+ 		return;
+ 
+ 	gic_set_kvm_info(&gic_v2_kvm_info);
+ }
+ 
  int __init
  gic_of_init(struct device_node *node, struct device_node *parent)
  {
@@@ -1294,17 -1235,18 +1319,19 @@@
  	 * Disable split EOI/Deactivate if either HYP is not available
  	 * or the CPU interface is too small.
  	 */
 -	if (gic_cnt == 0 && !gic_check_eoimode(node, &cpu_base))
 +	if (gic_cnt == 0 && !gic_check_eoimode(node, &gic->raw_cpu_base))
  		static_key_slow_dec(&supports_deactivate);
  
 -	if (of_property_read_u32(node, "cpu-offset", &percpu_offset))
 -		percpu_offset = 0;
 +	ret = __gic_init_bases(gic, -1, &node->fwnode);
 +	if (ret) {
 +		gic_teardown(gic);
 +		return ret;
 +	}
  
- 	if (!gic_cnt)
 -	__gic_init_bases(gic_cnt, -1, dist_base, cpu_base, percpu_offset,
 -			 &node->fwnode);
+ 	if (!gic_cnt) {
  		gic_init_physaddr(node);
+ 		gic_of_setup_kvm_info(node);
+ 	}
  
  	if (parent) {
  		irq = irq_of_parse_and_map(node, 0);
@@@ -1401,8 -1391,8 +1476,8 @@@ static int __init gic_v2_acpi_init(stru
  		return -EINVAL;
  	}
  
- 	gic->raw_cpu_base = ioremap(cpu_phy_base, ACPI_GIC_CPU_IF_MEM_SIZE);
 -	cpu_base = ioremap(acpi_data.cpu_phys_base, ACPI_GIC_CPU_IF_MEM_SIZE);
 -	if (!cpu_base) {
++	gic->raw_cpu_base = ioremap(acpi_data.cpu_phys_base, ACPI_GIC_CPU_IF_MEM_SIZE);
 +	if (!gic->raw_cpu_base) {
  		pr_err("Unable to map GICC registers\n");
  		return -ENOMEM;
  	}

^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2015-06-19  4:59 Michael Ellerman
  0 siblings, 0 replies; 49+ messages in thread
From: Michael Ellerman @ 2015-06-19  4:59 UTC (permalink / raw)
  To: Marcelo Tosatti, Gleb Natapov, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Nadav Amit, Paolo Bonzini,
	Radim Krčmář

Hi all,

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

  arch/x86/kvm/lapic.c

between commit:

  b6ac06953221 "KVM: x86: fix lapic.timer_mode on restore"

from the tip tree and commit:

  90de4a187518 "KVM: x86: Support for disabling quirks"

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

cheers


diff --cc arch/x86/kvm/lapic.c
index 4c7deb4f78a1,beeef05bb4d9..000000000000
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@@ -1581,9 -1588,10 +1593,11 @@@ void kvm_lapic_reset(struct kvm_vcpu *v
  
  	for (i = 0; i < APIC_LVT_NUM; i++)
  		apic_set_reg(apic, APIC_LVTT + 0x10 * i, APIC_LVT_MASKED);
 -	apic->lapic_timer.timer_mode = 0;
++
 +	apic_update_lvtt(apic);
- 	apic_set_reg(apic, APIC_LVT0,
- 		     SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT));
+ 	if (!(vcpu->kvm->arch.disabled_quirks & KVM_QUIRK_LINT0_REENABLED))
+ 		apic_set_reg(apic, APIC_LVT0,
+ 			     SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT));
  
  	apic_set_reg(apic, APIC_DFR, 0xffffffffU);
  	apic_set_spiv(apic, 0xff);





^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2015-05-26  4:45 Stephen Rothwell
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Rothwell @ 2015-05-26  4:45 UTC (permalink / raw)
  To: Marcelo Tosatti, Gleb Natapov, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Nadav Amit

[-- Attachment #1: Type: text/plain, Size: 2675 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got conflicts in
arch/x86/include/asm/kvm_host.h and arch/x86/kvm/x86.c between commit
0ee6a5172573 ("x86/fpu, kvm: Simplify fx_init()") (and a few others)
from the tip tree and commit d28bc9dd25ce ("KVM: x86: INIT and reset
sequences are different") from the kvm tree.

I fixed it up (since the former commit made fx_init() static, I just
removed the declaration and see below) and can carry the fix as
necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/kvm/x86.c
index 989cfc01e2a5,457b908244f2..000000000000
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@@ -7002,11 -7088,19 +7089,13 @@@ int kvm_arch_vcpu_ioctl_set_fpu(struct 
  	return 0;
  }
  
- static void fx_init(struct kvm_vcpu *vcpu)
 -int fx_init(struct kvm_vcpu *vcpu, bool init_event)
++static void fx_init(struct kvm_vcpu *vcpu, bool init_event)
  {
- 	fpstate_init(&vcpu->arch.guest_fpu.state);
 -	int err;
 -
 -	err = fpu_alloc(&vcpu->arch.guest_fpu);
 -	if (err)
 -		return err;
 -
+ 	if (!init_event)
 -		fpu_finit(&vcpu->arch.guest_fpu);
++		fpstate_init(&vcpu->arch.guest_fpu.state);
+ 
  	if (cpu_has_xsaves)
 -		vcpu->arch.guest_fpu.state->xsave.xsave_hdr.xcomp_bv =
 +		vcpu->arch.guest_fpu.state.xsave.header.xcomp_bv =
  			host_xcr0 | XSTATE_COMPACTION_ENABLED;
  
  	/*
@@@ -7038,16 -7140,25 +7127,25 @@@ void kvm_put_guest_fpu(struct kvm_vcpu 
  {
  	kvm_put_guest_xcr0(vcpu);
  
- 	if (!vcpu->guest_fpu_loaded)
+ 	if (!vcpu->guest_fpu_loaded) {
+ 		vcpu->fpu_counter = 0;
  		return;
+ 	}
  
  	vcpu->guest_fpu_loaded = 0;
 -	fpu_save_init(&vcpu->arch.guest_fpu);
 +	copy_fpregs_to_fpstate(&vcpu->arch.guest_fpu);
  	__kernel_fpu_end();
  	++vcpu->stat.fpu_reload;
- 	if (!vcpu->arch.eager_fpu)
- 		kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
- 
+ 	/*
+ 	 * If using eager FPU mode, or if the guest is a frequent user
+ 	 * of the FPU, just leave the FPU active for next time.
+ 	 * Every 255 times fpu_counter rolls over to 0; a guest that uses
+ 	 * the FPU in bursts will revert to loading it on demand.
+ 	 */
+ 	if (!use_eager_fpu()) {
+ 		if (++vcpu->fpu_counter < 5)
+ 			kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
+ 	}
  	trace_kvm_fpu(0);
  }
  
@@@ -7346,7 -7450,9 +7445,7 @@@ int kvm_arch_vcpu_init(struct kvm_vcpu 
  		goto fail_free_mce_banks;
  	}
  
- 	fx_init(vcpu);
 -	r = fx_init(vcpu, false);
 -	if (r)
 -		goto fail_free_wbinvd_dirty_mask;
++	fx_init(vcpu, false);
  
  	vcpu->arch.ia32_tsc_adjust_msr = 0x0;
  	vcpu->arch.pv_time_enabled = false;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2012-11-30  4:26 Stephen Rothwell
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Rothwell @ 2012-11-30  4:26 UTC (permalink / raw)
  To: Avi Kivity, Marcelo Tosatti
  Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, Paul Turner

[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in
kernel/sched/core.c between commit 0a74bef8bed1 ("sched: Add an rq
migration call-back to sched_class") from the tip tree and commit
582b336ec2c0 ("sched: add notifier for cross-cpu migrations") from the
kvm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/sched/core.c
index 20fb760,c86b8b6..0000000
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@@ -953,10 -959,16 +960,18 @@@ void set_task_cpu(struct task_struct *p
  	trace_sched_migrate_task(p, new_cpu);
  
  	if (task_cpu(p) != new_cpu) {
+ 		struct task_migration_notifier tmn;
+ 
 +		if (p->sched_class->migrate_task_rq)
 +			p->sched_class->migrate_task_rq(p, new_cpu);
  		p->se.nr_migrations++;
  		perf_sw_event(PERF_COUNT_SW_CPU_MIGRATIONS, 1, NULL, 0);
+ 
+ 		tmn.task = p;
+ 		tmn.from_cpu = task_cpu(p);
+ 		tmn.to_cpu = new_cpu;
+ 
+ 		atomic_notifier_call_chain(&task_migration_notifier, 0, &tmn);
  	}
  
  	__set_task_cpu(p, new_cpu);

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: linux-next: manual merge of the kvm tree with the tip tree
  2012-05-16  7:14 Stephen Rothwell
@ 2012-05-16  7:53 ` Gleb Natapov
  0 siblings, 0 replies; 49+ messages in thread
From: Gleb Natapov @ 2012-05-16  7:53 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Avi Kivity, Marcelo Tosatti, linux-next, linux-kernel, Alan Cox,
	Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra

On Wed, May 16, 2012 at 05:14:35PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in
> arch/x86/include/asm/kvm_para.h between commit c3709e6734da ("x86, kvm:
> KVM paravirt kernels don't check for CPUID being unavailable") from the
> tip tree and commit 9b72d3b07dd9 ("KVM guest: make kvm_para_available()
> check hypervisor bit reading cpuid leaf") from the kvm tree.
> 
> Just context changes.  I fixed it up (see below) and can carry the fix as
> necessary.
Fix looks good to me.

> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc arch/x86/include/asm/kvm_para.h
> index 183922e,a7a7a94..0000000
> --- a/arch/x86/include/asm/kvm_para.h
> +++ b/arch/x86/include/asm/kvm_para.h
> @@@ -170,17 -178,16 +178,19 @@@ static inline int kvm_para_available(vo
>   	unsigned int eax, ebx, ecx, edx;
>   	char signature[13];
>   
>  +	if (boot_cpu_data.cpuid_level < 0)
>  +		return 0;	/* So we don't blow up on old processors */
>  +
> - 	cpuid(KVM_CPUID_SIGNATURE, &eax, &ebx, &ecx, &edx);
> - 	memcpy(signature + 0, &ebx, 4);
> - 	memcpy(signature + 4, &ecx, 4);
> - 	memcpy(signature + 8, &edx, 4);
> - 	signature[12] = 0;
> + 	if (cpu_has_hypervisor) {
> + 		cpuid(KVM_CPUID_SIGNATURE, &eax, &ebx, &ecx, &edx);
> + 		memcpy(signature + 0, &ebx, 4);
> + 		memcpy(signature + 4, &ecx, 4);
> + 		memcpy(signature + 8, &edx, 4);
> + 		signature[12] = 0;
>   
> - 	if (strcmp(signature, "KVMKVMKVM") == 0)
> - 		return 1;
> + 		if (strcmp(signature, "KVMKVMKVM") == 0)
> + 			return 1;
> + 	}
>   
>   	return 0;
>   }



--
			Gleb.

^ permalink raw reply	[flat|nested] 49+ messages in thread

* linux-next: manual merge of the kvm tree with the tip tree
@ 2012-05-16  7:14 Stephen Rothwell
  2012-05-16  7:53 ` Gleb Natapov
  0 siblings, 1 reply; 49+ messages in thread
From: Stephen Rothwell @ 2012-05-16  7:14 UTC (permalink / raw)
  To: Avi Kivity, Marcelo Tosatti
  Cc: linux-next, linux-kernel, Alan Cox, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, Gleb Natapov

[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in
arch/x86/include/asm/kvm_para.h between commit c3709e6734da ("x86, kvm:
KVM paravirt kernels don't check for CPUID being unavailable") from the
tip tree and commit 9b72d3b07dd9 ("KVM guest: make kvm_para_available()
check hypervisor bit reading cpuid leaf") from the kvm tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/include/asm/kvm_para.h
index 183922e,a7a7a94..0000000
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@@ -170,17 -178,16 +178,19 @@@ static inline int kvm_para_available(vo
  	unsigned int eax, ebx, ecx, edx;
  	char signature[13];
  
 +	if (boot_cpu_data.cpuid_level < 0)
 +		return 0;	/* So we don't blow up on old processors */
 +
- 	cpuid(KVM_CPUID_SIGNATURE, &eax, &ebx, &ecx, &edx);
- 	memcpy(signature + 0, &ebx, 4);
- 	memcpy(signature + 4, &ecx, 4);
- 	memcpy(signature + 8, &edx, 4);
- 	signature[12] = 0;
+ 	if (cpu_has_hypervisor) {
+ 		cpuid(KVM_CPUID_SIGNATURE, &eax, &ebx, &ecx, &edx);
+ 		memcpy(signature + 0, &ebx, 4);
+ 		memcpy(signature + 4, &ecx, 4);
+ 		memcpy(signature + 8, &edx, 4);
+ 		signature[12] = 0;
  
- 	if (strcmp(signature, "KVMKVMKVM") == 0)
- 		return 1;
+ 		if (strcmp(signature, "KVMKVMKVM") == 0)
+ 			return 1;
+ 	}
  
  	return 0;
  }

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

end of thread, other threads:[~2022-12-01  0:20 UTC | newest]

Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-17  5:25 linux-next: manual merge of the kvm tree with the tip tree Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2022-12-01  0:18 Stephen Rothwell
2022-12-01  0:14 Stephen Rothwell
2022-01-10  2:16 Stephen Rothwell
2022-01-10  2:28 ` Like Xu
2021-12-13 17:46 broonie
2021-12-13 18:14 ` Paolo Bonzini
2021-12-13 18:23 ` Mark Brown
2021-10-25  5:11 Stephen Rothwell
2021-10-21  2:39 Stephen Rothwell
2021-10-21 15:32 ` Borislav Petkov
2021-04-22  4:30 Stephen Rothwell
2021-04-22  4:45 ` Nadav Amit
2021-04-22  4:58   ` Stephen Rothwell
2021-04-22  6:29   ` Paolo Bonzini
2020-07-29  6:47 Stephen Rothwell
2020-06-02  4:53 Stephen Rothwell
2020-06-04  3:09 ` Stephen Rothwell
2020-01-16  2:48 Stephen Rothwell
2018-12-19  4:12 Stephen Rothwell
2018-12-17  5:22 Stephen Rothwell
2018-10-19  3:25 Stephen Rothwell
2018-08-08  3:54 Stephen Rothwell
2018-08-15  4:27 ` Stephen Rothwell
2018-08-06  5:12 Stephen Rothwell
2018-08-06  6:27 ` Tianyu Lan
2018-02-02  0:51 Stephen Rothwell
2018-01-15  2:39 Stephen Rothwell
2017-08-28  4:52 Stephen Rothwell
2017-09-04  6:09 ` Stephen Rothwell
2017-08-25  4:39 Stephen Rothwell
2017-08-25  6:39 ` Paolo Bonzini
2017-08-25 13:57   ` Tom Lendacky
2017-08-25 16:53     ` Brijesh Singh
2017-08-25 20:05       ` Paolo Bonzini
2017-08-25 20:41         ` Brijesh Singh
2017-08-25 20:42           ` Paolo Bonzini
2017-08-26  7:24             ` Ingo Molnar
2016-11-28  3:56 Stephen Rothwell
2016-11-17  3:50 Stephen Rothwell
2016-11-17  7:07 ` Thomas Gleixner
2016-11-17 21:31   ` Stephen Rothwell
2016-05-12  2:54 Stephen Rothwell
2016-05-12  2:54 ` Stephen Rothwell
2015-06-19  4:59 Michael Ellerman
2015-05-26  4:45 Stephen Rothwell
2012-11-30  4:26 Stephen Rothwell
2012-05-16  7:14 Stephen Rothwell
2012-05-16  7:53 ` Gleb Natapov

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.