[PATCH] KVM, SEV: fix merge conflict

[PATCH] KVM, SEV: fix merge conflict

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

A conflict between two patches leads to build failure for
the reference countingg in 'struct kvm', which moved into
the kvm_refcount structure:

arch/x86/kvm/svm/sev.c: In function 'kvm_lockdep_assert_sev_lock_held':
arch/x86/kvm/svm/sev.c:118:32: error: 'struct kvm' has no member named 'users_count'
  118 |         if (!refcount_read(&kvm->users_count))

Resolve this by changing the added reference the same way as
the other ones.

Fixes: 422c363f58a8 ("KVM, vfio: remove symbol_get(kvm_get_kvm_safe) from vfio")
Fixes: ba903f738249 ("KVM: SEV: Assert that kvm->lock is held when querying SEV+ support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/x86/kvm/svm/sev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 04accfaefd0d..63b57f3b3800 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -115,7 +115,7 @@ static __always_inline void kvm_lockdep_assert_sev_lock_held(struct kvm *kvm)
 	 * Querying SEV+ support is safe if there are no other references, i.e.
 	 * if concurrent initialization of SEV+ is impossible.
 	 */
-	if (!refcount_read(&kvm->users_count))
+	if (!refcount_read(&kvm->rc.users_count))
 		return;
 
 	/*
-- 
2.39.5

Re: [PATCH] KVM, SEV: fix merge conflict

[Sean Christopherson]

On Tue, May 19, 2026, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> A conflict between two patches leads to build failure for
> the reference countingg in 'struct kvm', which moved into
> the kvm_refcount structure:
> 
> arch/x86/kvm/svm/sev.c: In function 'kvm_lockdep_assert_sev_lock_held':
> arch/x86/kvm/svm/sev.c:118:32: error: 'struct kvm' has no member named 'users_count'
>   118 |         if (!refcount_read(&kvm->users_count))
> 
> Resolve this by changing the added reference the same way as
> the other ones.
> 
> Fixes: 422c363f58a8 ("KVM, vfio: remove symbol_get(kvm_get_kvm_safe) from vfio")

This isn't a merge conflict, it's a bug in wherever this commit is coming from.

> Fixes: ba903f738249 ("KVM: SEV: Assert that kvm->lock is held when querying SEV+ support")

Because this commit has been in Linus' tree since 7.1-rc1.

Re: [PATCH] KVM, SEV: fix merge conflict

[kernel test robot]

Hi Arnd,

kernel test robot noticed the following build errors:

[auto build test ERROR on kvm/queue]
[also build test ERROR on kvm/next linus/master v7.1-rc4 next-20260519]
[cannot apply to kvm/linux-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Arnd-Bergmann/KVM-SEV-fix-merge-conflict/20260520-043413
base:   https://git.kernel.org/pub/scm/virt/kvm/kvm.git queue
patch link:    https://lore.kernel.org/r/20260519202851.1339906-1-arnd%40kernel.org
patch subject: [PATCH] KVM, SEV: fix merge conflict
config: x86_64-allmodconfig (https://download.01.org/0day-ci/archive/20260520/202605201112.NU8iRNQm-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260520/202605201112.NU8iRNQm-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605201112.NU8iRNQm-lkp@intel.com/

All errors (new ones prefixed by >>):

>> arch/x86/kvm/svm/sev.c:117:27: error: no member named 'rc' in 'struct kvm'
     117 |         if (!refcount_read(&kvm->rc.users_count))
         |                             ~~~  ^
   1 error generated.


vim +117 arch/x86/kvm/svm/sev.c

   109	
   110	static __always_inline void kvm_lockdep_assert_sev_lock_held(struct kvm *kvm)
   111	{
   112	#ifdef CONFIG_PROVE_LOCKING
   113		/*
   114		 * Querying SEV+ support is safe if there are no other references, i.e.
   115		 * if concurrent initialization of SEV+ is impossible.
   116		 */
 > 117		if (!refcount_read(&kvm->rc.users_count))
   118			return;
   119	
   120		/*
   121		 * Querying SEV+ support from vCPU context is always safe, as vCPUs can
   122		 * only be created after SEV+ is initialized (and KVM disallows all SEV
   123		 * sub-ioctls while vCPU creation is in-progress).
   124		 */
   125		if (kvm_get_running_vcpu())
   126			return;
   127	
   128		lockdep_assert_held(&kvm->lock);
   129	#endif
   130	}
   131	

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH] KVM, SEV: fix merge conflict

[kernel test robot]

Hi Arnd,

kernel test robot noticed the following build errors:

[auto build test ERROR on kvm/queue]
[also build test ERROR on kvm/next linus/master v7.1-rc4 next-20260519]
[cannot apply to kvm/linux-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Arnd-Bergmann/KVM-SEV-fix-merge-conflict/20260520-043413
base:   https://git.kernel.org/pub/scm/virt/kvm/kvm.git queue
patch link:    https://lore.kernel.org/r/20260519202851.1339906-1-arnd%40kernel.org
patch subject: [PATCH] KVM, SEV: fix merge conflict
config: x86_64-rhel-9.4-kselftests (https://download.01.org/0day-ci/archive/20260520/202605201202.pnbQfWkV-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260520/202605201202.pnbQfWkV-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605201202.pnbQfWkV-lkp@intel.com/

All errors (new ones prefixed by >>):

   arch/x86/kvm/svm/sev.c: In function 'kvm_lockdep_assert_sev_lock_held':
>> arch/x86/kvm/svm/sev.c:117:32: error: 'struct kvm' has no member named 'rc'
     117 |         if (!refcount_read(&kvm->rc.users_count))
         |                                ^~


vim +117 arch/x86/kvm/svm/sev.c

   109	
   110	static __always_inline void kvm_lockdep_assert_sev_lock_held(struct kvm *kvm)
   111	{
   112	#ifdef CONFIG_PROVE_LOCKING
   113		/*
   114		 * Querying SEV+ support is safe if there are no other references, i.e.
   115		 * if concurrent initialization of SEV+ is impossible.
   116		 */
 > 117		if (!refcount_read(&kvm->rc.users_count))
   118			return;
   119	
   120		/*
   121		 * Querying SEV+ support from vCPU context is always safe, as vCPUs can
   122		 * only be created after SEV+ is initialized (and KVM disallows all SEV
   123		 * sub-ioctls while vCPU creation is in-progress).
   124		 */
   125		if (kvm_get_running_vcpu())
   126			return;
   127	
   128		lockdep_assert_held(&kvm->lock);
   129	#endif
   130	}
   131	

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH] KVM, SEV: fix merge conflict

[Arnd Bergmann]

On Tue, May 19, 2026, at 23:26, Sean Christopherson wrote:
> On Tue, May 19, 2026, Arnd Bergmann wrote:
>> From: Arnd Bergmann <arnd@arndb.de>
>> 
>> A conflict between two patches leads to build failure for
>> the reference countingg in 'struct kvm', which moved into
>> the kvm_refcount structure:
>> 
>> arch/x86/kvm/svm/sev.c: In function 'kvm_lockdep_assert_sev_lock_held':
>> arch/x86/kvm/svm/sev.c:118:32: error: 'struct kvm' has no member named 'users_count'
>>   118 |         if (!refcount_read(&kvm->users_count))
>> 
>> Resolve this by changing the added reference the same way as
>> the other ones.
>> 
>> Fixes: 422c363f58a8 ("KVM, vfio: remove symbol_get(kvm_get_kvm_safe) from vfio")
>
> This isn't a merge conflict, it's a bug in wherever this commit is coming from.

Right, my mistake, it's from a branch that is not in linux-next
yet, and I did the merge myself.

Sorry for the false report.

     Arnd