linux-next: manual merge of the kvm-x86 tree with the kvm-fixes tree

linux-next: manual merge of the kvm-x86 tree with the kvm-fixes tree

[Mark Brown]

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

Hi all,

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

  tools/testing/selftests/kvm/x86/nested_x2apic_test.c

between commits:

  b630929bcc4c8 ("KVM: selftests: Extend nested x2APIC test to validate disabling x2APIC virt")
  b0bc51910f039 ("KVM: selftests: Extend nested x2APIC test to validate using eVMCS for vmcs12")

from the kvm-fixes tree and commits:

  9b2f8146fcef9 ("KVM: selftests: Extend nested x2APIC test to validate disabling x2APIC virt")
  a4bab1c12fd52 ("KVM: selftests: Extend nested x2APIC test to validate using eVMCS for vmcs12")

from the kvm-x86 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 --combined tools/testing/selftests/kvm/x86/nested_x2apic_test.c
index ce204ce29a9c0,2ae698c9aa1ce..0000000000000
--- a/tools/testing/selftests/kvm/x86/nested_x2apic_test.c
+++ b/tools/testing/selftests/kvm/x86/nested_x2apic_test.c
@@@ -61,57 -61,55 +61,57 @@@ static void l1_vmx_code(struct vmx_page
  		evmcs_enable();
  	}
  
 -	prepare_for_vmx_operation(vmx);
 +	GUEST_ASSERT_EQ(prepare_for_vmx_operation(vmx), true);
  
  	if (hv_pages) {
 -		load_evmcs(hv_pages);
 +		GUEST_ASSERT(load_evmcs(hv_pages));
  		current_evmcs->hv_enlightenments_control.msr_bitmap = 1;
  	} else {
 -		load_vmcs(vmx);
 +		GUEST_ASSERT(load_vmcs(vmx));
  	}
  
  	prepare_vmcs(vmx, NULL);
- 	GUEST_ASSERT_EQ(vmwrite(GUEST_RIP, (unsigned long)l2_guest_code), 0);
+ 	vmwrite(GUEST_RIP, (unsigned long)l2_guest_code);
  
 -	control = vmread(PIN_BASED_VM_EXEC_CONTROL);
 +	control = vmreadz(PIN_BASED_VM_EXEC_CONTROL);
  	control |= PIN_BASED_EXT_INTR_MASK;
  	vmwrite(PIN_BASED_VM_EXEC_CONTROL, control);
  
 -	control = vmread(CPU_BASED_VM_EXEC_CONTROL);
 +	control = vmreadz(CPU_BASED_VM_EXEC_CONTROL);
  	control |= CPU_BASED_USE_MSR_BITMAPS | CPU_BASED_TPR_SHADOW;
 -	vmwrite(CPU_BASED_VM_EXEC_CONTROL, control);
 +	GUEST_ASSERT_EQ(vmwrite(CPU_BASED_VM_EXEC_CONTROL, control), 0);
  
 -	control = vmread(SECONDARY_VM_EXEC_CONTROL);
 +	control = vmreadz(SECONDARY_VM_EXEC_CONTROL);
  	control |= SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE |
  		   SECONDARY_EXEC_APIC_REGISTER_VIRT |
  		   SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY;
  	control &= (rdmsr(MSR_IA32_VMX_PROCBASED_CTLS2) >> 32);
 -	vmwrite(SECONDARY_VM_EXEC_CONTROL, control);
 +	GUEST_ASSERT_EQ(vmwrite(SECONDARY_VM_EXEC_CONTROL, control), 0);
  
 -	vmlaunch();
 -	GUEST_ASSERT_EQ(vmread(VM_EXIT_REASON), EXIT_REASON_CPUID);
 -	vmwrite(GUEST_RIP, vmread(GUEST_RIP) + vmread(VM_EXIT_INSTRUCTION_LEN));
 +	GUEST_ASSERT(!vmlaunch());
 +	GUEST_ASSERT_EQ(vmreadz(VM_EXIT_REASON), EXIT_REASON_CPUID);
 +	GUEST_ASSERT_EQ(vmwrite(GUEST_RIP,
 +			vmreadz(GUEST_RIP) + vmreadz(VM_EXIT_INSTRUCTION_LEN)), 0);
  }
  
  static void l1_vmx_code_part2(void)
  {
  	u64 control;
  
 -	control = vmread(CPU_BASED_VM_EXEC_CONTROL);
 +	control = vmreadz(CPU_BASED_VM_EXEC_CONTROL);
  	control &= ~CPU_BASED_TPR_SHADOW;
 -	vmwrite(CPU_BASED_VM_EXEC_CONTROL, control);
 +	GUEST_ASSERT_EQ(vmwrite(CPU_BASED_VM_EXEC_CONTROL, control), 0);
  
 -	control = vmread(SECONDARY_VM_EXEC_CONTROL);
 +	control = vmreadz(SECONDARY_VM_EXEC_CONTROL);
  	control &= ~(SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE |
  			SECONDARY_EXEC_APIC_REGISTER_VIRT |
  			SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY);
 -	vmwrite(SECONDARY_VM_EXEC_CONTROL, control);
 +	GUEST_ASSERT_EQ(vmwrite(SECONDARY_VM_EXEC_CONTROL, control), 0);
  
 -	vmresume();
 -	GUEST_ASSERT_EQ(vmread(VM_EXIT_REASON), EXIT_REASON_CPUID);
 -	vmwrite(GUEST_RIP, vmread(GUEST_RIP) + vmread(VM_EXIT_INSTRUCTION_LEN));
 +	GUEST_ASSERT(!vmresume());
 +	GUEST_ASSERT_EQ(vmreadz(VM_EXIT_REASON), EXIT_REASON_CPUID);
 +	GUEST_ASSERT_EQ(vmwrite(GUEST_RIP,
 +			vmreadz(GUEST_RIP) + vmreadz(VM_EXIT_INSTRUCTION_LEN)), 0);
  }
  
  static void l1_test_x2apic_intercepts(void)

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

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

[Sean Christopherson]

On Wed, Sep 30, 2026, Mark Brown wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm-x86 tree got a conflict in:
> 
>   tools/testing/selftests/kvm/x86/nested_x2apic_test.c
> 
> between commits:
> 
>   b630929bcc4c8 ("KVM: selftests: Extend nested x2APIC test to validate disabling x2APIC virt")
>   b0bc51910f039 ("KVM: selftests: Extend nested x2APIC test to validate using eVMCS for vmcs12")
> 
> from the kvm-fixes tree and commits:
> 
>   9b2f8146fcef9 ("KVM: selftests: Extend nested x2APIC test to validate disabling x2APIC virt")
>   a4bab1c12fd52 ("KVM: selftests: Extend nested x2APIC test to validate using eVMCS for vmcs12")

kvm-fixes got force-pushed, which is what's causing the weird conflict.  In a
tree that hasn't refresh from kvm.git, I see:

  a4bab1c12fd528ccaafee00360e07463873404a9 (kvm/master, kvm/HEAD) KVM: selftests: Extend nested x2APIC test to validate using eVMCS for vmcs12
  9b2f8146fcef9faa73f9dc1bad9a8d6c585cfec8 KVM: selftests: Extend nested x2APIC test to validate disabling x2APIC virt

versus the newer version:

  973ea70393e885e540f714904e51bc6cac80e3d7 (kvm/master, kvm/HEAD) KVM: SEV: Do cache maintenance on the source VM *before* clearing SEV state
  8abbc76120a74bfba1851bd97528099d715e45c6 KVM: SEV: Nullify "have run CPUs" mask pointer when freeing it
  b0bc51910f0391fea09c0a1d32352fec2acb2686 KVM: selftests: Extend nested x2APIC test to validate using eVMCS for vmcs12
  b630929bcc4c867c9abc8cd5a0ebee3bb5ce5dcd KVM: selftests: Extend nested x2APIC test to validate disabling x2APIC virt

Ahh, I see the difference.  Paolo fixed up the Author:

  commit 9b2f8146fcef9faa73f9dc1bad9a8d6c585cfec8
  Author:     Paolo Bonzini <pbonzini@redhat.com>
  AuthorDate: Sat Sep 26 02:04:03 2026 -0400
  Commit:     Paolo Bonzini <pbonzini@redhat.com>
  CommitDate: Sat Sep 26 02:22:15 2026 -0400

versus:

  commit b630929bcc4c867c9abc8cd5a0ebee3bb5ce5dcd
  Author:     Sean Christopherson <seanjc@google.com>
  AuthorDate: Sat Sep 26 02:04:03 2026 -0400
  Commit:     Paolo Bonzini <pbonzini@redhat.com>
  CommitDate: Mon Sep 28 17:11:47 2026 -0400

> from the kvm-x86 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 --combined tools/testing/selftests/kvm/x86/nested_x2apic_test.c
> index ce204ce29a9c0,2ae698c9aa1ce..0000000000000
> --- a/tools/testing/selftests/kvm/x86/nested_x2apic_test.c
> +++ b/tools/testing/selftests/kvm/x86/nested_x2apic_test.c
> @@@ -61,57 -61,55 +61,57 @@@ static void l1_vmx_code(struct vmx_page
>   		evmcs_enable();
>   	}
>   
>  -	prepare_for_vmx_operation(vmx);
>  +	GUEST_ASSERT_EQ(prepare_for_vmx_operation(vmx), true);

This resolution will probably break the final selftests build?  kvm-x86/next
moves these asserts into prepare_for_vmx_operation(), load_evmcs(), load_vmcs()
etc.  I.e. kvm-x86/next should "win".

Regardless, I'll rebase kvm-x86/fixes onto the new kvm/master and rebuild kvm-x86/next,
so this should go away.

>   
>   	if (hv_pages) {
>  -		load_evmcs(hv_pages);
>  +		GUEST_ASSERT(load_evmcs(hv_pages));
>   		current_evmcs->hv_enlightenments_control.msr_bitmap = 1;
>   	} else {
>  -		load_vmcs(vmx);
>  +		GUEST_ASSERT(load_vmcs(vmx));
>   	}
>   
>   	prepare_vmcs(vmx, NULL);
> - 	GUEST_ASSERT_EQ(vmwrite(GUEST_RIP, (unsigned long)l2_guest_code), 0);
> + 	vmwrite(GUEST_RIP, (unsigned long)l2_guest_code);
>   
>  -	control = vmread(PIN_BASED_VM_EXEC_CONTROL);
>  +	control = vmreadz(PIN_BASED_VM_EXEC_CONTROL);
>   	control |= PIN_BASED_EXT_INTR_MASK;
>   	vmwrite(PIN_BASED_VM_EXEC_CONTROL, control);
>   
>  -	control = vmread(CPU_BASED_VM_EXEC_CONTROL);
>  +	control = vmreadz(CPU_BASED_VM_EXEC_CONTROL);
>   	control |= CPU_BASED_USE_MSR_BITMAPS | CPU_BASED_TPR_SHADOW;
>  -	vmwrite(CPU_BASED_VM_EXEC_CONTROL, control);
>  +	GUEST_ASSERT_EQ(vmwrite(CPU_BASED_VM_EXEC_CONTROL, control), 0);
>   
>  -	control = vmread(SECONDARY_VM_EXEC_CONTROL);
>  +	control = vmreadz(SECONDARY_VM_EXEC_CONTROL);
>   	control |= SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE |
>   		   SECONDARY_EXEC_APIC_REGISTER_VIRT |
>   		   SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY;
>   	control &= (rdmsr(MSR_IA32_VMX_PROCBASED_CTLS2) >> 32);
>  -	vmwrite(SECONDARY_VM_EXEC_CONTROL, control);
>  +	GUEST_ASSERT_EQ(vmwrite(SECONDARY_VM_EXEC_CONTROL, control), 0);
>   
>  -	vmlaunch();
>  -	GUEST_ASSERT_EQ(vmread(VM_EXIT_REASON), EXIT_REASON_CPUID);
>  -	vmwrite(GUEST_RIP, vmread(GUEST_RIP) + vmread(VM_EXIT_INSTRUCTION_LEN));
>  +	GUEST_ASSERT(!vmlaunch());
>  +	GUEST_ASSERT_EQ(vmreadz(VM_EXIT_REASON), EXIT_REASON_CPUID);
>  +	GUEST_ASSERT_EQ(vmwrite(GUEST_RIP,
>  +			vmreadz(GUEST_RIP) + vmreadz(VM_EXIT_INSTRUCTION_LEN)), 0);


>   }
>   
>   static void l1_vmx_code_part2(void)
>   {
>   	u64 control;
>   
>  -	control = vmread(CPU_BASED_VM_EXEC_CONTROL);
>  +	control = vmreadz(CPU_BASED_VM_EXEC_CONTROL);
>   	control &= ~CPU_BASED_TPR_SHADOW;
>  -	vmwrite(CPU_BASED_VM_EXEC_CONTROL, control);
>  +	GUEST_ASSERT_EQ(vmwrite(CPU_BASED_VM_EXEC_CONTROL, control), 0);
>   
>  -	control = vmread(SECONDARY_VM_EXEC_CONTROL);
>  +	control = vmreadz(SECONDARY_VM_EXEC_CONTROL);
>   	control &= ~(SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE |
>   			SECONDARY_EXEC_APIC_REGISTER_VIRT |
>   			SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY);
>  -	vmwrite(SECONDARY_VM_EXEC_CONTROL, control);
>  +	GUEST_ASSERT_EQ(vmwrite(SECONDARY_VM_EXEC_CONTROL, control), 0);
>   
>  -	vmresume();
>  -	GUEST_ASSERT_EQ(vmread(VM_EXIT_REASON), EXIT_REASON_CPUID);
>  -	vmwrite(GUEST_RIP, vmread(GUEST_RIP) + vmread(VM_EXIT_INSTRUCTION_LEN));
>  +	GUEST_ASSERT(!vmresume());
>  +	GUEST_ASSERT_EQ(vmreadz(VM_EXIT_REASON), EXIT_REASON_CPUID);
>  +	GUEST_ASSERT_EQ(vmwrite(GUEST_RIP,
>  +			vmreadz(GUEST_RIP) + vmreadz(VM_EXIT_INSTRUCTION_LEN)), 0);
>   }
>   
>   static void l1_test_x2apic_intercepts(void)

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

[Mark Brown]

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

On Wed, Sep 30, 2026 at 06:40:07AM -0700, Sean Christopherson wrote:
> On Wed, Sep 30, 2026, Mark Brown wrote:

> > between commits:

> >   b630929bcc4c8 ("KVM: selftests: Extend nested x2APIC test to validate disabling x2APIC virt")
> >   b0bc51910f039 ("KVM: selftests: Extend nested x2APIC test to validate using eVMCS for vmcs12")

> > from the kvm-fixes tree and commits:

> >   9b2f8146fcef9 ("KVM: selftests: Extend nested x2APIC test to validate disabling x2APIC virt")
> >   a4bab1c12fd52 ("KVM: selftests: Extend nested x2APIC test to validate using eVMCS for vmcs12")

> kvm-fixes got force-pushed, which is what's causing the weird conflict.  In a
> tree that hasn't refresh from kvm.git, I see:

Ah, I had thought it was an old version of the patch having landed in
kvm-x86.  It looked like different versions of the same patch got into
each tree so I went with the main fixes branch version as that's what's
heading for Linus.  This sort of cherry pick/duplicate stuff is always
hard to follow. :(

>   a4bab1c12fd528ccaafee00360e07463873404a9 (kvm/master, kvm/HEAD) KVM: selftests: Extend nested x2APIC test to validate using eVMCS for vmcs12
>   9b2f8146fcef9faa73f9dc1bad9a8d6c585cfec8 KVM: selftests: Extend nested x2APIC test to validate disabling x2APIC virt

> versus the newer version:

>   973ea70393e885e540f714904e51bc6cac80e3d7 (kvm/master, kvm/HEAD) KVM: SEV: Do cache maintenance on the source VM *before* clearing SEV state
>   8abbc76120a74bfba1851bd97528099d715e45c6 KVM: SEV: Nullify "have run CPUs" mask pointer when freeing it
>   b0bc51910f0391fea09c0a1d32352fec2acb2686 KVM: selftests: Extend nested x2APIC test to validate using eVMCS for vmcs12
>   b630929bcc4c867c9abc8cd5a0ebee3bb5ce5dcd KVM: selftests: Extend nested x2APIC test to validate disabling x2APIC virt

IIRC my conflict resolution gitk only showed me the two commits that got
duplicated, it is filtered by file though.

> >  -	prepare_for_vmx_operation(vmx);
> >  +	GUEST_ASSERT_EQ(prepare_for_vmx_operation(vmx), true);

> This resolution will probably break the final selftests build?  kvm-x86/next
> moves these asserts into prepare_for_vmx_operation(), load_evmcs(), load_vmcs()
> etc.  I.e. kvm-x86/next should "win".

That's entirely plausible, my kselftest build tests are for arm64 only
since that's what's native on the build machine.  Sorry about the mess
here.  If you send me a confirmed resolution on top of today's -next I
can add the fixup, or I'll try to take look tomorrow?

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

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

[Sean Christopherson]

On Wed, Sep 30, 2026, Mark Brown wrote:
> On Wed, Sep 30, 2026 at 06:40:07AM -0700, Sean Christopherson wrote:
> > On Wed, Sep 30, 2026, Mark Brown wrote:
> 
> > > between commits:
> 
> > >   b630929bcc4c8 ("KVM: selftests: Extend nested x2APIC test to validate disabling x2APIC virt")
> > >   b0bc51910f039 ("KVM: selftests: Extend nested x2APIC test to validate using eVMCS for vmcs12")
> 
> > > from the kvm-fixes tree and commits:
> 
> > >   9b2f8146fcef9 ("KVM: selftests: Extend nested x2APIC test to validate disabling x2APIC virt")
> > >   a4bab1c12fd52 ("KVM: selftests: Extend nested x2APIC test to validate using eVMCS for vmcs12")
> 
> > kvm-fixes got force-pushed, which is what's causing the weird conflict.  In a
> > tree that hasn't refresh from kvm.git, I see:
> 
> Ah, I had thought it was an old version of the patch having landed in
> kvm-x86.  It looked like different versions of the same patch got into
> each tree so I went with the main fixes branch version as that's what's
> heading for Linus.  This sort of cherry pick/duplicate stuff is always
> hard to follow. :(
> 
> >   a4bab1c12fd528ccaafee00360e07463873404a9 (kvm/master, kvm/HEAD) KVM: selftests: Extend nested x2APIC test to validate using eVMCS for vmcs12
> >   9b2f8146fcef9faa73f9dc1bad9a8d6c585cfec8 KVM: selftests: Extend nested x2APIC test to validate disabling x2APIC virt
> 
> > versus the newer version:
> 
> >   973ea70393e885e540f714904e51bc6cac80e3d7 (kvm/master, kvm/HEAD) KVM: SEV: Do cache maintenance on the source VM *before* clearing SEV state
> >   8abbc76120a74bfba1851bd97528099d715e45c6 KVM: SEV: Nullify "have run CPUs" mask pointer when freeing it
> >   b0bc51910f0391fea09c0a1d32352fec2acb2686 KVM: selftests: Extend nested x2APIC test to validate using eVMCS for vmcs12
> >   b630929bcc4c867c9abc8cd5a0ebee3bb5ce5dcd KVM: selftests: Extend nested x2APIC test to validate disabling x2APIC virt
> 
> IIRC my conflict resolution gitk only showed me the two commits that got
> duplicated, it is filtered by file though.
> 
> > >  -	prepare_for_vmx_operation(vmx);
> > >  +	GUEST_ASSERT_EQ(prepare_for_vmx_operation(vmx), true);
> 
> > This resolution will probably break the final selftests build?  kvm-x86/next
> > moves these asserts into prepare_for_vmx_operation(), load_evmcs(), load_vmcs()
> > etc.  I.e. kvm-x86/next should "win".
> 
> That's entirely plausible, my kselftest build tests are for arm64 only
> since that's what's native on the build machine.  Sorry about the mess
> here.

Ha, no need to apologize, it's our mess.

> If you send me a confirmed resolution on top of today's -next I
> can add the fixup, or I'll try to take look tomorrow?

Here's the fixup.  I'll make sure to push to kvm-x86/next today with the new
version of kvm/master, so this should disappear in tomorrow's build.

diff --git a/tools/testing/selftests/kvm/x86/nested_x2apic_test.c b/tools/testing/selftests/kvm/x86/nested_x2apic_test.c
index 52959287500d..2ae698c9aa1c 100644
--- a/tools/testing/selftests/kvm/x86/nested_x2apic_test.c
+++ b/tools/testing/selftests/kvm/x86/nested_x2apic_test.c
@@ -61,57 +61,55 @@ static void l1_vmx_code(struct vmx_pages *vmx, struct hyperv_test_pages *hv_page
 		evmcs_enable();
 	}
 
-	GUEST_ASSERT_EQ(prepare_for_vmx_operation(vmx), true);
+	prepare_for_vmx_operation(vmx);
 
 	if (hv_pages) {
-		GUEST_ASSERT(load_evmcs(hv_pages));
+		load_evmcs(hv_pages);
 		current_evmcs->hv_enlightenments_control.msr_bitmap = 1;
 	} else {
-		GUEST_ASSERT(load_vmcs(vmx));
+		load_vmcs(vmx);
 	}
 
 	prepare_vmcs(vmx, NULL);
 	vmwrite(GUEST_RIP, (unsigned long)l2_guest_code);
 
-	control = vmreadz(PIN_BASED_VM_EXEC_CONTROL);
+	control = vmread(PIN_BASED_VM_EXEC_CONTROL);
 	control |= PIN_BASED_EXT_INTR_MASK;
 	vmwrite(PIN_BASED_VM_EXEC_CONTROL, control);
 
-	control = vmreadz(CPU_BASED_VM_EXEC_CONTROL);
+	control = vmread(CPU_BASED_VM_EXEC_CONTROL);
 	control |= CPU_BASED_USE_MSR_BITMAPS | CPU_BASED_TPR_SHADOW;
-	GUEST_ASSERT_EQ(vmwrite(CPU_BASED_VM_EXEC_CONTROL, control), 0);
+	vmwrite(CPU_BASED_VM_EXEC_CONTROL, control);
 
-	control = vmreadz(SECONDARY_VM_EXEC_CONTROL);
+	control = vmread(SECONDARY_VM_EXEC_CONTROL);
 	control |= SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE |
 		   SECONDARY_EXEC_APIC_REGISTER_VIRT |
 		   SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY;
 	control &= (rdmsr(MSR_IA32_VMX_PROCBASED_CTLS2) >> 32);
-	GUEST_ASSERT_EQ(vmwrite(SECONDARY_VM_EXEC_CONTROL, control), 0);
+	vmwrite(SECONDARY_VM_EXEC_CONTROL, control);
 
-	GUEST_ASSERT(!vmlaunch());
-	GUEST_ASSERT_EQ(vmreadz(VM_EXIT_REASON), EXIT_REASON_CPUID);
-	GUEST_ASSERT_EQ(vmwrite(GUEST_RIP,
-			vmreadz(GUEST_RIP) + vmreadz(VM_EXIT_INSTRUCTION_LEN)), 0);
+	vmlaunch();
+	GUEST_ASSERT_EQ(vmread(VM_EXIT_REASON), EXIT_REASON_CPUID);
+	vmwrite(GUEST_RIP, vmread(GUEST_RIP) + vmread(VM_EXIT_INSTRUCTION_LEN));
 }
 
 static void l1_vmx_code_part2(void)
 {
 	u64 control;
 
-	control = vmreadz(CPU_BASED_VM_EXEC_CONTROL);
+	control = vmread(CPU_BASED_VM_EXEC_CONTROL);
 	control &= ~CPU_BASED_TPR_SHADOW;
-	GUEST_ASSERT_EQ(vmwrite(CPU_BASED_VM_EXEC_CONTROL, control), 0);
+	vmwrite(CPU_BASED_VM_EXEC_CONTROL, control);
 
-	control = vmreadz(SECONDARY_VM_EXEC_CONTROL);
+	control = vmread(SECONDARY_VM_EXEC_CONTROL);
 	control &= ~(SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE |
 			SECONDARY_EXEC_APIC_REGISTER_VIRT |
 			SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY);
-	GUEST_ASSERT_EQ(vmwrite(SECONDARY_VM_EXEC_CONTROL, control), 0);
+	vmwrite(SECONDARY_VM_EXEC_CONTROL, control);
 
-	GUEST_ASSERT(!vmresume());
-	GUEST_ASSERT_EQ(vmreadz(VM_EXIT_REASON), EXIT_REASON_CPUID);
-	GUEST_ASSERT_EQ(vmwrite(GUEST_RIP,
-			vmreadz(GUEST_RIP) + vmreadz(VM_EXIT_INSTRUCTION_LEN)), 0);
+	vmresume();
+	GUEST_ASSERT_EQ(vmread(VM_EXIT_REASON), EXIT_REASON_CPUID);
+	vmwrite(GUEST_RIP, vmread(GUEST_RIP) + vmread(VM_EXIT_INSTRUCTION_LEN));
 }
 
 static void l1_test_x2apic_intercepts(void)

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

[Mark Brown]

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

On Thu, Mar 12, 2026 at 06:54:18PM +0100, Paolo Bonzini wrote:
> On 3/12/26 18:21, Mark Brown wrote:

> >   -	ret = enter_svm_guest_mode(vcpu, smram64->svm_guest_vmcb_gpa, false);
> > - 	if (nested_svm_check_cached_vmcb12(vcpu) < 0)
> > - 		goto unmap_save;

> The right resolution is to keep these two lines...

Yeah, that was the bit about the prior resolution being wrong.

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

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

[Sean Christopherson]

On Thu, Mar 12, 2026, Paolo Bonzini wrote:
> On 3/12/26 18:21, Mark Brown wrote:
> > diff --cc arch/x86/kvm/svm/svm.c
> > index e6477affac9a0,3407deac90bd6..0000000000000
> > --- a/arch/x86/kvm/svm/svm.c
> > +++ b/arch/x86/kvm/svm/svm.c
> > @@@ -4880,15 -5030,11 +5030,11 @@@ static int svm_leave_smm(struct kvm_vcp
> >    	vmcb12 = map.hva;
> >    	nested_copy_vmcb_control_to_cache(svm, &vmcb12->control);
> >    	nested_copy_vmcb_save_to_cache(svm, &vmcb12->save);
> >   -	ret = enter_svm_guest_mode(vcpu, smram64->svm_guest_vmcb_gpa, false);
> > - 	if (nested_svm_check_cached_vmcb12(vcpu) < 0)
> > - 		goto unmap_save;
> 
> The right resolution is to keep these two lines...
> 
> > -
> > - 	if (enter_svm_guest_mode(vcpu, smram64->svm_guest_vmcb_gpa,
> > - 				 vmcb12, false) != 0)
> >   -	if (ret)
> > ++	if (enter_svm_guest_mode(vcpu, smram64->svm_guest_vmcb_gpa, false) != 0)
> 
> ... while of course this part is okay.

I'm in the process of redoing kvm-x86/next on top of kvm/next, so I'll sort this
out on my end (and double check that I come up with the same resolution as Paolo).

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

[Paolo Bonzini]

On 3/12/26 18:21, Mark Brown wrote:
> diff --cc arch/x86/kvm/svm/svm.c
> index e6477affac9a0,3407deac90bd6..0000000000000
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@@ -4880,15 -5030,11 +5030,11 @@@ static int svm_leave_smm(struct kvm_vcp
>    	vmcb12 = map.hva;
>    	nested_copy_vmcb_control_to_cache(svm, &vmcb12->control);
>    	nested_copy_vmcb_save_to_cache(svm, &vmcb12->save);
>   -	ret = enter_svm_guest_mode(vcpu, smram64->svm_guest_vmcb_gpa, false);
>    
> - 	if (nested_svm_check_cached_vmcb12(vcpu) < 0)
> - 		goto unmap_save;

The right resolution is to keep these two lines...

> -
> - 	if (enter_svm_guest_mode(vcpu, smram64->svm_guest_vmcb_gpa,
> - 				 vmcb12, false) != 0)
>   -	if (ret)
> ++	if (enter_svm_guest_mode(vcpu, smram64->svm_guest_vmcb_gpa, false) != 0)

... while of course this part is okay.

Paolo

>    		goto unmap_save;
>    
>   +	ret = 0;
>    	svm->nested.nested_run_pending = 1;
>    
>    unmap_save:

linux-next: manual merge of the kvm-x86 tree with the kvm-fixes tree

[Mark Brown]

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

Hi all,

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

  arch/x86/kvm/svm/svm.c

between commit:

  6b1ca262a943a ("KVM: x86: clarify leave_smm() return value")

from the kvm-fixes tree and commit:

  84dc9fd0354d3 ("KVM: nSVM: Cache all used fields from VMCB12")

from the kvm-x86 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 suspect this may be flagging an issue with the merge I just posted and
removal of the check for the cache...

diff --cc arch/x86/kvm/svm/svm.c
index e6477affac9a0,3407deac90bd6..0000000000000
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@@ -4880,15 -5030,11 +5030,11 @@@ static int svm_leave_smm(struct kvm_vcp
  	vmcb12 = map.hva;
  	nested_copy_vmcb_control_to_cache(svm, &vmcb12->control);
  	nested_copy_vmcb_save_to_cache(svm, &vmcb12->save);
 -	ret = enter_svm_guest_mode(vcpu, smram64->svm_guest_vmcb_gpa, false);
  
- 	if (nested_svm_check_cached_vmcb12(vcpu) < 0)
- 		goto unmap_save;
- 
- 	if (enter_svm_guest_mode(vcpu, smram64->svm_guest_vmcb_gpa,
- 				 vmcb12, false) != 0)
 -	if (ret)
++	if (enter_svm_guest_mode(vcpu, smram64->svm_guest_vmcb_gpa, false) != 0)
  		goto unmap_save;
  
 +	ret = 0;
  	svm->nested.nested_run_pending = 1;
  
  unmap_save:

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

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

[Sean Christopherson]

On Wed, Apr 03, 2024, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm-x86 tree got a conflict in:
> 
>   tools/testing/selftests/kvm/include/x86_64/processor.h
> 
> between commit:
> 
>   0d1756482e66 ("Merge tag 'kvm-x86-pvunhalt-6.9' of https://github.com/kvm-x86/linux into HEAD")
> 
> from the kvm-fixes tree and commit:
> 
>   964d0c614c7f ("Merge branch 'hyperv'")
> 
> from the kvm-x86 tree.
> 
> I fixed it up (I used the former version)

Perfect, I'll drop my branch.  Thanks!

linux-next: manual merge of the kvm-x86 tree with the kvm-fixes tree

[Stephen Rothwell]

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

Hi all,

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

  tools/testing/selftests/kvm/include/x86_64/processor.h

between commit:

  0d1756482e66 ("Merge tag 'kvm-x86-pvunhalt-6.9' of https://github.com/kvm-x86/linux into HEAD")

from the kvm-fixes tree and commit:

  964d0c614c7f ("Merge branch 'hyperv'")

from the kvm-x86 tree.

I fixed it up (I used the former version) 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 --]