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

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

[Stephen Rothwell]

[-- 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 --]

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

[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.
> 

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

[Stephen Rothwell]

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

Hi all,

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

  arch/x86/kvm/reverse_cpuid.h

between commit:

  15fea09b029d ("x86/cpu, kvm: Add support for CPUID_80000021_EAX")

from the tip tree and commit:

  0fcf86f05af2 ("KVM: x86: Add a KVM-only leaf for CPUID_8000_0007_EDX")

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/reverse_cpuid.h
index 81f4e9ce0c77,4945456fd646..000000000000
--- a/arch/x86/kvm/reverse_cpuid.h
+++ b/arch/x86/kvm/reverse_cpuid.h
@@@ -68,7 -72,7 +72,8 @@@ static const struct cpuid_reg reverse_c
  	[CPUID_12_EAX]        = {0x00000012, 0, CPUID_EAX},
  	[CPUID_8000_001F_EAX] = {0x8000001f, 0, CPUID_EAX},
  	[CPUID_7_1_EDX]       = {         7, 1, CPUID_EDX},
 +	[CPUID_8000_0021_EAX] = {0x80000021, 0, CPUID_EAX},
+ 	[CPUID_8000_0007_EDX] = {0x80000007, 0, CPUID_EDX},
  };
  
  /*

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

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

[Stephen Rothwell]

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

Hi all,

On Thu, 1 Dec 2022 11:14:08 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> 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 */

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

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Like Xu]

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.

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

[Stephen Rothwell]

[-- 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 --]

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

[Mark Brown]

[-- 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 --]

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

[Paolo Bonzini]

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

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

[broonie]

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 \

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

[Stephen Rothwell]

[-- 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 --]

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

[Borislav Petkov]

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

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

[Stephen Rothwell]

[-- 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 --]

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

[Paolo Bonzini]

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.
> 

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

[Stephen Rothwell]

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

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

[Nadav Amit]

> 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.

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

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)

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

[Stephen Rothwell]

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
  	/*

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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);
  

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

[Ingo Molnar]

* 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

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

[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

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

[Brijesh Singh]

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

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

[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);
> 
> 

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

[Brijesh Singh]

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
>>

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

[Tom Lendacky]

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
> 

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

[Paolo Bonzini]

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

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

[Stephen Rothwell]

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);

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

[Stephen Rothwell]

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"

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

[Stephen Rothwell]

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

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

[Thomas Gleixner]

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

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

[Stephen Rothwell]

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)

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

[Stephen Rothwell]

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;
  	}

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

[Stephen Rothwell]

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;
  	}

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

[Michael Ellerman]

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);

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Gleb Natapov]

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.

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

[Stephen Rothwell]

[-- 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 --]