linux-next: build failure after merge of the kvm-x86 tree

linux-next: build failure after merge of the kvm-x86 tree

[Stephen Rothwell]

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

Hi all,

After merging the kvm-x86 tree, today's linux-next build (x86_64
allmodconfig) failed like this:

arch/x86/kvm/../../../virt/kvm/guest_memfd.c: In function 'kvm_gmem_get_file':
arch/x86/kvm/../../../virt/kvm/guest_memfd.c:280:35: error: passing argument 1 of 'get_file_rcu' from incompatible pointer type [-Werror=incompatible-pointer-types]
  280 |         if (file && !get_file_rcu(file))
      |                                   ^~~~
      |                                   |
      |                                   struct file *
In file included from include/linux/backing-dev.h:13,
                 from arch/x86/kvm/../../../virt/kvm/guest_memfd.c:2:
include/linux/fs.h:1046:47: note: expected 'struct file **' but argument is of type 'struct file *'
 1046 | struct file *get_file_rcu(struct file __rcu **f);
      |                           ~~~~~~~~~~~~~~~~~~~~^

Caused by commit

  fcbef1e5e5d2 ("KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory")

interacting with commit

  0ede61d8589c ("file: convert to SLAB_TYPESAFE_BY_RCU")

from the vfs-brauner tree.

I have applied the following merg resolution patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 30 Oct 2023 13:35:38 +1100
Subject: [PATCH] fix up for "KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for
 guest-specific backing memory"

interacting with "file: convert to SLAB_TYPESAFE_BY_RCU"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 virt/kvm/guest_memfd.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
index 94bc478c26f3..7f62abe3df9e 100644
--- a/virt/kvm/guest_memfd.c
+++ b/virt/kvm/guest_memfd.c
@@ -276,9 +276,7 @@ static struct file *kvm_gmem_get_file(struct kvm_memory_slot *slot)
 
 	rcu_read_lock();
 
-	file = rcu_dereference(slot->gmem.file);
-	if (file && !get_file_rcu(file))
-		file = NULL;
+	file = get_file_rcu(&slot->gmem.file);
 
 	rcu_read_unlock();
 
-- 
2.40.1

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build failure after merge of the kvm-x86 tree

[Christian Brauner]

On Mon, Oct 30, 2023 at 01:48:06PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the kvm-x86 tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> arch/x86/kvm/../../../virt/kvm/guest_memfd.c: In function 'kvm_gmem_get_file':
> arch/x86/kvm/../../../virt/kvm/guest_memfd.c:280:35: error: passing argument 1 of 'get_file_rcu' from incompatible pointer type [-Werror=incompatible-pointer-types]
>   280 |         if (file && !get_file_rcu(file))
>       |                                   ^~~~
>       |                                   |
>       |                                   struct file *
> In file included from include/linux/backing-dev.h:13,
>                  from arch/x86/kvm/../../../virt/kvm/guest_memfd.c:2:
> include/linux/fs.h:1046:47: note: expected 'struct file **' but argument is of type 'struct file *'
>  1046 | struct file *get_file_rcu(struct file __rcu **f);
>       |                           ~~~~~~~~~~~~~~~~~~~~^
> 
> Caused by commit
> 
>   fcbef1e5e5d2 ("KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory")
> 
> interacting with commit
> 
>   0ede61d8589c ("file: convert to SLAB_TYPESAFE_BY_RCU")
> 
> from the vfs-brauner tree.
> 
> I have applied the following merg resolution patch:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 30 Oct 2023 13:35:38 +1100
> Subject: [PATCH] fix up for "KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for
>  guest-specific backing memory"
> 
> interacting with "file: convert to SLAB_TYPESAFE_BY_RCU"
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  virt/kvm/guest_memfd.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> index 94bc478c26f3..7f62abe3df9e 100644
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
> @@ -276,9 +276,7 @@ static struct file *kvm_gmem_get_file(struct kvm_memory_slot *slot)
>  
>  	rcu_read_lock();
>  
> -	file = rcu_dereference(slot->gmem.file);
> -	if (file && !get_file_rcu(file))
> -		file = NULL;
> +	file = get_file_rcu(&slot->gmem.file);
>  
>  	rcu_read_unlock();

Stephen, thanks for the suggested fixup.

Afaict, the guest_memfds pin the kvm instance. If a guest_memfd is
closed and last fput() is called the file pointer remains stashed in all
relevant gmem->file slots until guest_memfd->release::kvm_gmem_release()
is called. And kvm_gmem_release() sets all relevant gmem->file instances
to NULL via rcu_assign_pointer().

So afaict, the gmem->file pointer isn't part of the reference counting
but rather it just caches the result of the reference counting. And it's
then cleared when that reference goes down to zero.

Basically, I think this is akin to commit 61d4fb0b349e ("file, i915: fix
file reference for mmap_singleton()") which is in -next and the
discussion we had in
https://lore.kernel.org/r/20231025-formfrage-watscheln-84526cd3bd7d@brauner

So that means we can't to loop here which is what get_file_rcu() would
do. Otherwise you might end up spinning. Because last close of
guest_memfd fput() puts the last reference. Now all concurrent
gmem->file kvm_gmem_get_file() callers will see f_count at zero. And it
might well take a while until the kernel calls
guest_memfd->release::kvm_gmem_release() and NULLs the pointer. So
get_file_rcu() would retry and loop because it thinks that the pointer
is part of the reference counting.

So iiuc you want get_file_active() here which also takes the
rcu_read_lock() for you.

@Paolo and @Sean, does that make sense and is the series for v6.7 or
just already in -next for v6.8?

diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
index 94bc478c26f3..a4c194b0b22c 100644
--- a/virt/kvm/guest_memfd.c
+++ b/virt/kvm/guest_memfd.c
@@ -272,17 +272,7 @@ static int kvm_gmem_release(struct inode *inode, struct file *file)

 static struct file *kvm_gmem_get_file(struct kvm_memory_slot *slot)
 {
-       struct file *file;
-
-       rcu_read_lock();
-
-       file = rcu_dereference(slot->gmem.file);
-       if (file && !get_file_rcu(file))
-               file = NULL;
-
-       rcu_read_unlock();
-
-       return file;
+       return get_file_active(&slot->gmem.file);
 }

 static struct file_operations kvm_gmem_fops = {

Re: linux-next: build failure after merge of the kvm-x86 tree

[Paolo Bonzini]

On 10/30/23 11:05, Christian Brauner wrote:
> 
> @Paolo and @Sean, does that make sense and is the series for v6.7 or
> just already in -next for v6.8?

It's for 6.8.  Thanks for the fixup!

Paolo

> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> index 94bc478c26f3..a4c194b0b22c 100644
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
> @@ -272,17 +272,7 @@ static int kvm_gmem_release(struct inode *inode, struct file *file)
> 
>  static struct file *kvm_gmem_get_file(struct kvm_memory_slot *slot)
>  {
> -       struct file *file;
> -
> -       rcu_read_lock();
> -
> -       file = rcu_dereference(slot->gmem.file);
> -       if (file && !get_file_rcu(file))
> -               file = NULL;
> -
> -       rcu_read_unlock();
> -
> -       return file;
> +       return get_file_active(&slot->gmem.file);
>  }
> 
>  static struct file_operations kvm_gmem_fops = {
> 

Re: linux-next: build failure after merge of the kvm-x86 tree

[Stephen Rothwell]

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

Hi Paolo,

On Mon, 30 Oct 2023 12:27:07 +0100 Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 10/30/23 11:05, Christian Brauner wrote:
> > 
> > @Paolo and @Sean, does that make sense and is the series for v6.7 or
> > just already in -next for v6.8?  
> 
> It's for 6.8.

Then it should not be in linux-next yet. :-(
-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build failure after merge of the kvm-x86 tree

[Sean Christopherson]

On Tue, Oct 31, 2023, Stephen Rothwell wrote:
> Hi Paolo,
> 
> On Mon, 30 Oct 2023 12:27:07 +0100 Paolo Bonzini <pbonzini@redhat.com> wrote:
> >
> > On 10/30/23 11:05, Christian Brauner wrote:
> > > 
> > > @Paolo and @Sean, does that make sense and is the series for v6.7 or
> > > just already in -next for v6.8?  
> > 
> > It's for 6.8.
> 
> Then it should not be in linux-next yet. :-(

That's my bad, I wanted to get the guest_memfd code exposure asap and jumped the
gun.  I'll yank the branch out kvm-x86/next.

I assume -rc1 is when the floodgates "officially" open again?

Re: linux-next: build failure after merge of the kvm-x86 tree

[Stephen Rothwell]

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

Hi Sean,

On Mon, 30 Oct 2023 14:05:12 -0700 Sean Christopherson <seanjc@google.com> wrote:
>
> That's my bad, I wanted to get the guest_memfd code exposure asap and jumped the
> gun.  I'll yank the branch out kvm-x86/next.

Thanks.

> I assume -rc1 is when the floodgates "officially" open again?

Yes, indeed.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build failure after merge of the kvm-x86 tree

[Paolo Bonzini]

On Mon, Oct 30, 2023 at 10:10 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Sean,
>
> On Mon, 30 Oct 2023 14:05:12 -0700 Sean Christopherson <seanjc@google.com> wrote:
> >
> > That's my bad, I wanted to get the guest_memfd code exposure asap and jumped the
> > gun.  I'll yank the branch out kvm-x86/next.
>
> Thanks.

In all fairness, it was only recently pushed back from 6.7 to 6.8 so
it probably would have made sense to include it _even earlier_. But I
agree that at this point it's better if we wait for 6.7-rc1 before it
makes it back into linux-next. At that point I'll include the conflict
resolution myself.

Paolo

linux-next: build failure after merge of the kvm-x86 tree

[Mark Brown]

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

Hi all,

After merging the kvm-x86 tree, today's linux-next build
(arm64 kselftest) failed like this:

arm64/vgic_its_save.c: In function 'alloc_64k':
arm64/vgic_its_save.c:289:21: error: too many arguments to function
'vm_phy_pages_alloc'
  289 |         gpa_t gpa = vm_phy_pages_alloc(vm, nr * pages_per_64k, gpa_base,
      |                     ^~~~~~~~~~~~~~~~~~
In file included from arm64/vgic_its_save.c:24:
include/kvm_util.h:1062:21: note: declared here
 1062 | static inline gpa_t vm_phy_pages_alloc(struct kvm_vm *vm, size_t nr_pages,
      |                     ^~~~~~~~~~~~~~~~~~

Caused by commits

  36a062568ea80 (KVM: selftests: Take the memory region type, not memslot, in page allocators)
  6c28a0d7cf125 (KVM: selftests: Automatically pick min_gpa for allocations based on region type)

interacting with commit

  6f182db39fb00 (KVM: arm64: selftests: Add ITS table save tests)

from the kvm-arm tree.  I have applied the fixup below and can carry as
needed:

From ceedc17041d689c99453d14f867d6b0badc8da8b Mon Sep 17 00:00:00 2001
From: Mark Brown <broonie@kernel.org>
Date: Wed, 16 Sep 2026 14:18:38 +0100
Subject: [PATCH] KVM: selftests: Fix up phy_pages_alloc() API rework
 interaction

arm64/vgic_its_save.c: In function 'alloc_64k':
arm64/vgic_its_save.c:289:21: error: too many arguments to function
'vm_phy_pages_alloc'
  289 |         gpa_t gpa = vm_phy_pages_alloc(vm, nr * pages_per_64k, gpa_base,
      |                     ^~~~~~~~~~~~~~~~~~
In file included from arm64/vgic_its_save.c:24:
include/kvm_util.h:1062:21: note: declared here
 1062 | static inline gpa_t vm_phy_pages_alloc(struct kvm_vm *vm, size_t nr_pages,
      |                     ^~~~~~~~~~~~~~~~~~

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 tools/testing/selftests/kvm/arm64/vgic_its_save.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/kvm/arm64/vgic_its_save.c b/tools/testing/selftests/kvm/arm64/vgic_its_save.c
index 864da01539f3f..9a8a65fd7196b 100644
--- a/tools/testing/selftests/kvm/arm64/vgic_its_save.c
+++ b/tools/testing/selftests/kvm/arm64/vgic_its_save.c
@@ -286,8 +286,8 @@ static void setup_memslot(size_t sz)
 static gpa_t alloc_64k(size_t nr)
 {
 	size_t pages_per_64k = vm_calc_num_guest_pages(vm->mode, SZ_64K);
-	gpa_t gpa = vm_phy_pages_alloc(vm, nr * pages_per_64k, gpa_base,
-				       TEST_MEMSLOT_INDEX);
+	gpa_t gpa = vm_phy_pages_alloc(vm, nr * pages_per_64k,
+				       MEM_REGION_TEST_EXTRA);
 
 	TEST_ASSERT(IS_ALIGNED(gpa, SZ_64K),
 		    "Allocation at 0x%lx is not 64K aligned, GITS_BASER cannot address it",
-- 
2.47.3


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

Re: linux-next: build failure after merge of the kvm-x86 tree

[Sean Christopherson]

On Wed, Sep 16, 2026, Mark Brown wrote:
> Hi all,
> 
> After merging the kvm-x86 tree, today's linux-next build
> (arm64 kselftest) failed like this:
> 
> arm64/vgic_its_save.c: In function 'alloc_64k':
> arm64/vgic_its_save.c:289:21: error: too many arguments to function
> 'vm_phy_pages_alloc'
>   289 |         gpa_t gpa = vm_phy_pages_alloc(vm, nr * pages_per_64k, gpa_base,
>       |                     ^~~~~~~~~~~~~~~~~~
> In file included from arm64/vgic_its_save.c:24:
> include/kvm_util.h:1062:21: note: declared here
>  1062 | static inline gpa_t vm_phy_pages_alloc(struct kvm_vm *vm, size_t nr_pages,
>       |                     ^~~~~~~~~~~~~~~~~~
> 
> Caused by commits
> 
>   36a062568ea80 (KVM: selftests: Take the memory region type, not memslot, in page allocators)
>   6c28a0d7cf125 (KVM: selftests: Automatically pick min_gpa for allocations based on region type)

In case anyone cares, I'm woefully behind on sending "thanks".  These came from
the prep series for enabling PPC selftests.

https://lore.kernel.org/all/20260826230511.972824-1-seanjc@google.com

> interacting with commit
> 
>   6f182db39fb00 (KVM: arm64: selftests: Add ITS table save tests)
> 
> from the kvm-arm tree.  I have applied the fixup below and can carry as
> needed:

Given that this is in "fixes", I assume the new test will land in 7.3?  If so,
this is mostly my problem to deal with when sending Paolo the selftests pull
(which, FWIW, I'm hoping to do this week so that it can be used as the base for
PPC selftests support). 

> diff --git a/tools/testing/selftests/kvm/arm64/vgic_its_save.c b/tools/testing/selftests/kvm/arm64/vgic_its_save.c
> index 864da01539f3f..9a8a65fd7196b 100644
> --- a/tools/testing/selftests/kvm/arm64/vgic_its_save.c
> +++ b/tools/testing/selftests/kvm/arm64/vgic_its_save.c
> @@ -286,8 +286,8 @@ static void setup_memslot(size_t sz)
>  static gpa_t alloc_64k(size_t nr)
>  {
>  	size_t pages_per_64k = vm_calc_num_guest_pages(vm->mode, SZ_64K);
> -	gpa_t gpa = vm_phy_pages_alloc(vm, nr * pages_per_64k, gpa_base,
> -				       TEST_MEMSLOT_INDEX);
> +	gpa_t gpa = vm_phy_pages_alloc(vm, nr * pages_per_64k,
> +				       MEM_REGION_TEST_EXTRA);

The test also needs to override/define the memory region.  Not fully tested, but
I think it's this:

diff --git a/tools/testing/selftests/kvm/arm64/vgic_its_save.c b/tools/testing/selftests/kvm/arm64/vgic_its_save.c
index 864da01539f3..fae8a6c45f88 100644
--- a/tools/testing/selftests/kvm/arm64/vgic_its_save.c
+++ b/tools/testing/selftests/kvm/arm64/vgic_its_save.c
@@ -279,15 +279,15 @@ static void setup_memslot(size_t sz)
 	size_t pages = sz / vm->page_size;
 
 	gpa_base = ((vm_compute_max_gfn(vm) + 1) * vm->page_size) - sz;
-	vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS, gpa_base,
-				    TEST_MEMSLOT_INDEX, pages, 0);
+	vm_override_mem_region(vm, MEM_REGION_TEST_EXTRA, VM_MEM_SRC_ANONYMOUS,
+			       gpa_base, TEST_MEMSLOT_INDEX, pages);
 }
 
 static gpa_t alloc_64k(size_t nr)
 {
 	size_t pages_per_64k = vm_calc_num_guest_pages(vm->mode, SZ_64K);
-	gpa_t gpa = vm_phy_pages_alloc(vm, nr * pages_per_64k, gpa_base,
-				       TEST_MEMSLOT_INDEX);
+	gpa_t gpa = vm_phy_pages_alloc(vm, nr * pages_per_64k,
+				       MEM_REGION_TEST_EXTRA);
 
 	TEST_ASSERT(IS_ALIGNED(gpa, SZ_64K),
 		    "Allocation at 0x%lx is not 64K aligned, GITS_BASER cannot address it",

Re: linux-next: build failure after merge of the kvm-x86 tree

[Mark Brown]

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

On Wed, Sep 16, 2026 at 07:04:49AM -0700, Sean Christopherson wrote:

> The test also needs to override/define the memory region.  Not fully tested, but
> I think it's this:

Thanks for checking, I'll roll your fixup into my resolution tomorrow
unless someone says otherwise.

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

Re: linux-next: build failure after merge of the kvm-x86 tree

[Oliver Upton]

Hey,

On Wed, Sep 16, 2026 at 07:04:49AM -0700, Sean Christopherson wrote:
> On Wed, Sep 16, 2026, Mark Brown wrote:
> > Hi all,
> > 
> > After merging the kvm-x86 tree, today's linux-next build
> > (arm64 kselftest) failed like this:
> > 
> > arm64/vgic_its_save.c: In function 'alloc_64k':
> > arm64/vgic_its_save.c:289:21: error: too many arguments to function
> > 'vm_phy_pages_alloc'
> >   289 |         gpa_t gpa = vm_phy_pages_alloc(vm, nr * pages_per_64k, gpa_base,
> >       |                     ^~~~~~~~~~~~~~~~~~
> > In file included from arm64/vgic_its_save.c:24:
> > include/kvm_util.h:1062:21: note: declared here
> >  1062 | static inline gpa_t vm_phy_pages_alloc(struct kvm_vm *vm, size_t nr_pages,
> >       |                     ^~~~~~~~~~~~~~~~~~
> > 
> > Caused by commits
> > 
> >   36a062568ea80 (KVM: selftests: Take the memory region type, not memslot, in page allocators)
> >   6c28a0d7cf125 (KVM: selftests: Automatically pick min_gpa for allocations based on region type)
> 
> In case anyone cares, I'm woefully behind on sending "thanks".  These came from
> the prep series for enabling PPC selftests.
> 
> https://lore.kernel.org/all/20260826230511.972824-1-seanjc@google.com
> 
> > interacting with commit
> > 
> >   6f182db39fb00 (KVM: arm64: selftests: Add ITS table save tests)
> > 
> > from the kvm-arm tree.  I have applied the fixup below and can carry as
> > needed:
> 
> Given that this is in "fixes", I assume the new test will land in 7.3?  If so,
> this is mostly my problem to deal with when sending Paolo the selftests pull
> (which, FWIW, I'm hoping to do this week so that it can be used as the base for
> PPC selftests support). 

Yeah, aim here is to have the selftest go with the fix which I'll send to
Paolo this week. Sorry for the churn.

> diff --git a/tools/testing/selftests/kvm/arm64/vgic_its_save.c b/tools/testing/selftests/kvm/arm64/vgic_its_save.c
> index 864da01539f3..fae8a6c45f88 100644
> --- a/tools/testing/selftests/kvm/arm64/vgic_its_save.c
> +++ b/tools/testing/selftests/kvm/arm64/vgic_its_save.c
> @@ -279,15 +279,15 @@ static void setup_memslot(size_t sz)
>  	size_t pages = sz / vm->page_size;
>  
>  	gpa_base = ((vm_compute_max_gfn(vm) + 1) * vm->page_size) - sz;
> -	vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS, gpa_base,
> -				    TEST_MEMSLOT_INDEX, pages, 0);
> +	vm_override_mem_region(vm, MEM_REGION_TEST_EXTRA, VM_MEM_SRC_ANONYMOUS,
> +			       gpa_base, TEST_MEMSLOT_INDEX, pages);
>  }
>  
>  static gpa_t alloc_64k(size_t nr)
>  {
>  	size_t pages_per_64k = vm_calc_num_guest_pages(vm->mode, SZ_64K);
> -	gpa_t gpa = vm_phy_pages_alloc(vm, nr * pages_per_64k, gpa_base,
> -				       TEST_MEMSLOT_INDEX);
> +	gpa_t gpa = vm_phy_pages_alloc(vm, nr * pages_per_64k,
> +				       MEM_REGION_TEST_EXTRA);
>  
>  	TEST_ASSERT(IS_ALIGNED(gpa, SZ_64K),
>  		    "Allocation at 0x%lx is not 64K aligned, GITS_BASER cannot address it",

LGTM

Thanks,
Oliver

Re: linux-next: build failure after merge of the kvm-x86 tree

[Sean Christopherson]

On Wed, Sep 16, 2026, Oliver Upton wrote:
> > In case anyone cares, I'm woefully behind on sending "thanks".  These came from
> > the prep series for enabling PPC selftests.
> > 
> > https://lore.kernel.org/all/20260826230511.972824-1-seanjc@google.com
> > 
> > > interacting with commit
> > > 
> > >   6f182db39fb00 (KVM: arm64: selftests: Add ITS table save tests)
> > > 
> > > from the kvm-arm tree.  I have applied the fixup below and can carry as
> > > needed:
> > 
> > Given that this is in "fixes", I assume the new test will land in 7.3?  If so,
> > this is mostly my problem to deal with when sending Paolo the selftests pull
> > (which, FWIW, I'm hoping to do this week so that it can be used as the base for
> > PPC selftests support). 
> 
> Yeah, aim here is to have the selftest go with the fix which I'll send to
> Paolo this week. Sorry for the churn.

LOL, why are you apoligizing?  You added one test, I reworked all of the core
allocator APIs.  :-D

Re: linux-next: build failure after merge of the kvm-x86 tree

[Oliver Upton]

On Wed, Sep 16, 2026 at 09:43:14AM -0700, Sean Christopherson wrote:
> On Wed, Sep 16, 2026, Oliver Upton wrote:
> > > In case anyone cares, I'm woefully behind on sending "thanks".  These came from
> > > the prep series for enabling PPC selftests.
> > > 
> > > https://lore.kernel.org/all/20260826230511.972824-1-seanjc@google.com
> > > 
> > > > interacting with commit
> > > > 
> > > >   6f182db39fb00 (KVM: arm64: selftests: Add ITS table save tests)
> > > > 
> > > > from the kvm-arm tree.  I have applied the fixup below and can carry as
> > > > needed:
> > > 
> > > Given that this is in "fixes", I assume the new test will land in 7.3?  If so,
> > > this is mostly my problem to deal with when sending Paolo the selftests pull
> > > (which, FWIW, I'm hoping to do this week so that it can be used as the base for
> > > PPC selftests support). 
> > 
> > Yeah, aim here is to have the selftest go with the fix which I'll send to
> > Paolo this week. Sorry for the churn.
> 
> LOL, why are you apoligizing?  You added one test, I reworked all of the core
> allocator APIs.  :-D

I'm pretty sure you've conditioned everyone to endure at least one
KVM-wide rework every release ;-)

linux-next: build failure after merge of the kvm-x86 tree

[Stephen Rothwell]

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

Hi all,

After merging the kvm-x86 tree, today's linux-next build (x86_64
allmodconfig) failed like this:

arch/x86/kvm/svm/svm.c: In function 'svm_flush_tlb_all':
arch/x86/kvm/svm/svm.c:3852:17: error: implicit declaration of function 'hv_remote_flush_tlb' [-Werror=implicit-function-declaration]
 3852 |                 hv_remote_flush_tlb(vcpu->kvm);
      |                 ^~~~~~~~~~~~~~~~~~~

Caused by commit

  8a1300ff9518 ("KVM: x86: Rename Hyper-V remote TLB hooks to match established scheme")

interacting with commit

  e5c972c1fada ("KVM: SVM: Flush Hyper-V TLB when required")

from Linus' tree.

I have applied the following merge fix patch.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 11 Apr 2023 13:21:46 +1000
Subject: [PATCH] fixup for "KVM: x86: Rename Hyper-V remote TLB hooks to match established scheme"

interacting with "KVM: SVM: Flush Hyper-V TLB when required"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/kvm/kvm_onhyperv.h | 2 +-
 arch/x86/kvm/svm/svm.c      | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/kvm_onhyperv.h b/arch/x86/kvm/kvm_onhyperv.h
index 2d5f669c1ea1..f9ca3e7432b2 100644
--- a/arch/x86/kvm/kvm_onhyperv.h
+++ b/arch/x86/kvm/kvm_onhyperv.h
@@ -11,7 +11,7 @@ int hv_flush_remote_tlbs_range(struct kvm *kvm, gfn_t gfn, gfn_t nr_pages);
 int hv_flush_remote_tlbs(struct kvm *kvm);
 void hv_track_root_tdp(struct kvm_vcpu *vcpu, hpa_t root_tdp);
 #else /* !CONFIG_HYPERV */
-static inline int hv_remote_flush_tlb(struct kvm *kvm)
+static inline int hv_flush_remote_tlbs(struct kvm *kvm)
 {
 	return -EOPNOTSUPP;
 }
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index a9c940a31f3a..ca32389f3c36 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -3843,13 +3843,13 @@ static void svm_flush_tlb_all(struct kvm_vcpu *vcpu)
 {
 	/*
 	 * When running on Hyper-V with EnlightenedNptTlb enabled, remote TLB
-	 * flushes should be routed to hv_remote_flush_tlb() without requesting
+	 * flushes should be routed to hv_flush_remote_tlbs() without requesting
 	 * a "regular" remote flush.  Reaching this point means either there's
-	 * a KVM bug or a prior hv_remote_flush_tlb() call failed, both of
+	 * a KVM bug or a prior hv_flush_remote_tlbs() call failed, both of
 	 * which might be fatal to the guest.  Yell, but try to recover.
 	 */
 	if (WARN_ON_ONCE(svm_hv_is_enlightened_tlb_enabled(vcpu)))
-		hv_remote_flush_tlb(vcpu->kvm);
+		hv_flush_remote_tlbs(vcpu->kvm);
 
 	svm_flush_tlb_asid(vcpu);
 }
-- 
2.39.2

-- 
Cheers,
Stephen Rothwell

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