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


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

Hi all,

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

  arch/x86/kernel/kvm.c

between commits:

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

from the tip tree and commits:

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

from the kvm tree.

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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


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

Hi all,

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

  arch/x86/kernel/kvm.c

between commit:

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

from the tip tree and commit:

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

from the kvm tree.

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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


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

Hi all,

On Tue, 2 Jun 2020 14:53:58 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>   arch/x86/kernel/kvm.c
> 
> between commit:
> 
>   a707ae1a9bbb ("x86/entry: Switch page fault exception to IDTENTRY_RAW")
> 
> from the tip tree and commit:
> 
>   68fd66f100d1 ("KVM: x86: extend struct kvm_vcpu_pv_apf_data with token info")
> 
> from the kvm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/x86/kernel/kvm.c
> index 07dc47359c4f,d6f22a3a1f7d..000000000000
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@@ -217,23 -218,23 +217,23 @@@ again
>   }
>   EXPORT_SYMBOL_GPL(kvm_async_pf_task_wake);
>   
> - u32 noinstr kvm_read_and_reset_pf_reason(void)
>  -u32 kvm_read_and_reset_apf_flags(void)
> ++u32 noinstr kvm_read_and_reset_apf_flags(void)
>   {
> - 	u32 reason = 0;
> + 	u32 flags = 0;
>   
>   	if (__this_cpu_read(apf_reason.enabled)) {
> - 		reason = __this_cpu_read(apf_reason.reason);
> - 		__this_cpu_write(apf_reason.reason, 0);
> + 		flags = __this_cpu_read(apf_reason.flags);
> + 		__this_cpu_write(apf_reason.flags, 0);
>   	}
>   
> - 	return reason;
> + 	return flags;
>   }
> - EXPORT_SYMBOL_GPL(kvm_read_and_reset_pf_reason);
> + EXPORT_SYMBOL_GPL(kvm_read_and_reset_apf_flags);
>  -NOKPROBE_SYMBOL(kvm_read_and_reset_apf_flags);
>   
>  -bool __kvm_handle_async_pf(struct pt_regs *regs, u32 token)
>  +noinstr bool __kvm_handle_async_pf(struct pt_regs *regs, u32 token)
>   {
> - 	u32 reason = kvm_read_and_reset_pf_reason();
> + 	u32 reason = kvm_read_and_reset_apf_flags();
>  +	bool rcu_exit;
>   
>   	switch (reason) {
>   	case KVM_PV_REASON_PAGE_NOT_PRESENT:

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

-- 
Cheers,
Stephen Rothwell

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

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

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


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

Hi all,

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

  arch/x86/kernel/kvm.c

between commit:

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

from the tip tree and commit:

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

from the kvm tree.

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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


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

Hi all,

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

  arch/x86/include/asm/vmx.h

between commit:

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

from the tip tree and commits:

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

from the kvm tree.

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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


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

Hi all,

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

  arch/x86/kvm/x86.c

between commit:

  eb012ef3b4e3 ("x86: Remove Intel MPX")

from the tip tree and commit:

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

from the kvm tree.

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

-- 
Cheers,
Stephen Rothwell

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

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

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


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

Hi all,

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

  arch/x86/kvm/vmx.c

between commit:

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

from the tip tree and commit:

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

from the kvm tree.

I fixed it up (I removed the file and then made the same changes to
the file in its new position (one change was already fixed)) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index b8fa74ce3af2..c90fffdc5a93 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -2214,7 +2214,7 @@ static __init int alloc_kvm_area(void)
 		 * vmcs->revision_id to KVM_EVMCS_VERSION instead of
 		 * revision_id reported by MSR_IA32_VMX_BASIC.
 		 *
-		 * However, even though not explictly documented by
+		 * However, even though not explicitly documented by
 		 * TLFS, VMXArea passed as VMXON argument should
 		 * still be marked with revision_id reported by
 		 * physical CPU.

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

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

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


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

Hi all,

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

  tools/include/uapi/linux/kvm.h

between commit:

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

from the tip tree and commit:

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

from the kvm tree.

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

-- 
Cheers,
Stephen Rothwell

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

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

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


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

Hi all,

On Wed, 8 Aug 2018 13:54:45 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Paolo pointed out a semantic conflict between the kvm tree and the tip
> tree in
> 
>   arch/x86/kernel/kvm.c
> 
> between commit:
> 
>   368a540e0232 ("x86/kvmclock: Remove memblock dependency")
> 
> from the tip tree and commit:
> 
>   d63bae079b64 ("KVM: X86: Add kvm hypervisor init time platform setup callback")
> 
> from the kvm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> I applied the following (as suggested) after the automatic merge:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 8 Aug 2018 13:48:34 +1000
> Subject: [PATCH] kvm: x86: fix semantic conflict in platform init
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/x86/kernel/kvm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index 0906b8731393..e2499bad3209 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -714,13 +714,13 @@ static void __init kvm_apic_init(void)
>  static void __init kvm_init_platform(void)
>  {
>  	x86_platform.apic_post_init = kvm_apic_init;
> +	kvmclock_init();
>  }
>  
>  const __initconst struct hypervisor_x86 x86_hyper_kvm = {
>  	.name			= "KVM",
>  	.detect			= kvm_detect,
>  	.type			= X86_HYPER_KVM,
> -	.init.init_platform	= kvmclock_init,
>  	.init.guest_late_init	= kvm_guest_init,
>  	.init.x2apic_available	= kvm_para_available,
>  	.init.init_platform	= kvm_init_platform,
> -- 
> 2.18.0

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

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

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

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


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

Hi all,

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

  arch/x86/kernel/kvm.c

between commit:

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

from the tip tree and commit:

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

from the kvm tree.

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

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

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

On 8/6/2018 1:12 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>    arch/x86/include/asm/trace/hyperv.h
> 
> between commit:
> 
>    58ec5e9c9044 ("x86/hyper-v: Trace PV IPI send")
> 
> from the tip tree and commit:
> 
>    47c054685621 ("X86/Hyper-V: Add hyperv_nested_flush_guest_mapping ftrace support")
> 
> from the kvm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

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

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


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

Hi all,

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

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

between commit:

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

from the tip tree and commit:

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

from the kvm tree.

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

-- 
Cheers,
Stephen Rothwell

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

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

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

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

Hi all,

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

  arch/x86/kvm/vmx.c

between commit:

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

from the tip tree and commit:

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

from the kvm tree.

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

-- 
Cheers,
Stephen Rothwell

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

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

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

Hi all,

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

  arch/x86/kvm/vmx.c

between commit:

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

from the tip tree and commit:

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

from the kvm tree.

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

-- 
Cheers,
Stephen Rothwell

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

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

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

Hi all,

On Mon, 28 Aug 2017 14:52:09 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>   arch/x86/kvm/mmu.c
> 
> between commit:
> 
>   ea2800ddb20d ("kvm/x86: Avoid clearing the C-bit in rsvd_bits()")
> 
> from the tip tree and commit:
> 
>   d6321d493319 ("KVM: x86: generalize guest_cpuid_has_ helpers")
> 
> from the kvm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/x86/kvm/mmu.c
> index 04d750813c9d,2a8a6e3e2a31..000000000000
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@@ -4116,21 -4157,11 +4162,21 @@@ reset_shadow_zero_bits_mask(struct kvm_
>   	 * Passing "true" to the last argument is okay; it adds a check
>   	 * on bit 8 of the SPTEs which KVM doesn't use anyway.
>   	 */
>  -	__reset_rsvds_bits_mask(vcpu, &context->shadow_zero_check,
>  +	shadow_zero_check = &context->shadow_zero_check;
>  +	__reset_rsvds_bits_mask(vcpu, shadow_zero_check,
>   				boot_cpu_data.x86_phys_bits,
>   				context->shadow_root_level, uses_nx,
> - 				guest_cpuid_has_gbpages(vcpu), is_pse(vcpu),
> - 				true);
> + 				guest_cpuid_has(vcpu, X86_FEATURE_GBPAGES),
> + 				is_pse(vcpu), true);
>  +
>  +	if (!shadow_me_mask)
>  +		return;
>  +
>  +	for (i = context->shadow_root_level; --i >= 0;) {
>  +		shadow_zero_check->rsvd_bits_mask[0][i] &= ~shadow_me_mask;
>  +		shadow_zero_check->rsvd_bits_mask[1][i] &= ~shadow_me_mask;
>  +	}
>  +
>   }
>   EXPORT_SYMBOL_GPL(reset_shadow_zero_bits_mask);
>   

Just a reminder that this conflict still exists.

-- 
Cheers,
Stephen Rothwell

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

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

Hi all,

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

  arch/x86/kvm/mmu.c

between commit:

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

from the tip tree and commit:

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

from the kvm tree.

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

-- 
Cheers,
Stephen Rothwell

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

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

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


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

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

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

Thanks,

	Ingo

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

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

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

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

Paolo

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

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



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

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

Ingo,

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

-Brijesh

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

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

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

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

With that change, you can include my

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

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

Please use shadow_zero_check here too:

                __reset_rsvds_bits_mask_ept(&context->shadow_zero_check,

Thanks,

Paolo

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

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

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

Hi Paolo,


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

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

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

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





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

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

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

On 8/25/2017 1:39 AM, Paolo Bonzini wrote:
> On 25/08/2017 06:39, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the kvm tree got a conflict in:
>>
>>    arch/x86/kvm/mmu.h
>>
>> between commit:
>>
>>    d0ec49d4de90 ("kvm/x86/svm: Support Secure Memory Encryption within KVM")
>>
>> from the tip tree and commit:
>>
>>    d1cd3ce90044 ("KVM: MMU: check guest CR3 reserved bits based on its physical address width.")
>>
>> from the kvm tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary. This
>> is now fixed as far as linux-next is concerned, but any non trivial
>> conflicts should be mentioned to your upstream maintainer when your tree
>> is submitted for merging.  You may also want to consider cooperating
>> with the maintainer of the conflicting tree to minimise any particularly
>> complex conflicts.
>>
> 
> Thomas L., Ingo,
> 
> this is completely wrong:
> 
>>
>>   static inline u64 rsvd_bits(int s, int e)
>>   {
>> -	return ((1ULL << (e - s + 1)) - 1) << s;
>> +	return __sme_clr(((1ULL << (e - s + 1)) - 1) << s);
>>   }
>>   
> 
> First, rsvd_bits is just a simple function to return some 1 bits.  Applying
> a mask based on properties of the host MMU is incorrect.
> 
> Second, the masks computed by __reset_rsvds_bits_mask also apply to
> guest page tables, where the C bit is reserved since we don't emulate
> SME.
> 
> Something like this:

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

Thanks,
Tom

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

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

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

On 25/08/2017 06:39, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>   arch/x86/kvm/mmu.h
> 
> between commit:
> 
>   d0ec49d4de90 ("kvm/x86/svm: Support Secure Memory Encryption within KVM")
> 
> from the tip tree and commit:
> 
>   d1cd3ce90044 ("KVM: MMU: check guest CR3 reserved bits based on its physical address width.")
> 
> from the kvm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

Thomas L., Ingo,

this is completely wrong:

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

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

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

Something like this:

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

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

(And thanks Stephen for the heads-up!)

Paolo

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

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

Hi all,

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

  arch/x86/kvm/mmu.h

between commit:

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

from the tip tree and commit:

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

from the kvm tree.

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

-- 
Cheers,
Stephen Rothwell

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

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

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

Hi all,

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

  arch/x86/kvm/cpuid.c

between commit:

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

from the tip tree and commit:

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

from the kvm tree.

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

-- 
Cheers,
Stephen Rothwell

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

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

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

Hi Thomas,

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

Thanks for letting me know.

> tip will carry a proper resolution today.

Too easy.

-- 
Cheers,
Stephen Rothwell

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

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

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

This should be

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

tip will carry a proper resolution today.

Thanks,

	tglx

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

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

Hi all,

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

  arch/x86/kernel/cpu/scattered.c

between commit:

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

from the tip tree and commits:

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

from the kvm tree.

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

-- 
Cheers,
Stephen Rothwell

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

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

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

Hi all,

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

  drivers/irqchip/irq-gic.c

between commits:

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

from the tip tree and commits:

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

from the kvm tree.

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

-- 
Cheers,
Stephen Rothwell

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

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

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

Hi all,

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

  arch/x86/kvm/lapic.c

between commit:

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

from the tip tree and commit:

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

from the kvm tree.

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

cheers


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

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

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


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

Hi all,

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

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

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

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

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

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

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


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

Hi all,

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

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

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

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

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

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

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

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

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



--
			Gleb.

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

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


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

Hi all,

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

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

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

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

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

end of thread, back to index

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

Linux-Next Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-next/0 linux-next/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-next linux-next/ https://lore.kernel.org/linux-next \
		linux-next@vger.kernel.org
	public-inbox-index linux-next

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-next


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git