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

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

[Stephen Rothwell]

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

Hi all,

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

  arch/x86/include/asm/kvm_host.h

between commit:

  b0b42197b5c6 ("KVM: x86: start moving SMM-related functions to new files")

from the kvm tree and commit:

  e8a18565e593 ("KVM: Move declaration of kvm_cpu_dirty_log_size() to kvm_dirty_ring.h")

from the kvm-arm 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/kvm_host.h
index d1013c4f673c,b4dbde7d9eb1..000000000000
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@@ -2154,8 -2084,12 +2154,6 @@@ static inline int kvm_cpu_get_apicid(in
  #endif
  }
  
- int kvm_cpu_dirty_log_size(void);
 -#define put_smstate(type, buf, offset, val)                      \
 -	*(type *)((buf) + (offset) - 0x7e00) = val
 -
 -#define GET_SMSTATE(type, buf, offset)		\
 -	(*(type *)((buf) + (offset) - 0x7e00))
--
  int memslot_rmap_alloc(struct kvm_memory_slot *slot, unsigned long npages);
  
  #define KVM_CLOCK_VALID_FLAGS						\

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

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/kvm/arm.c

between commit:

  d8708b80fa0e ("KVM: Change return type of kvm_arch_vm_ioctl() to "int"")

from the kvm tree and commit:

  e0fc6b21616d ("KVM: arm64: Add vm fd device attribute accessors")

from the kvm-arm 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/arm64/kvm/arm.c
index aaa752be3776,4ec888fdd4f7..000000000000
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@@ -220,7 -234,7 +234,8 @@@ int kvm_vm_ioctl_check_extension(struc
  	case KVM_CAP_VCPU_ATTRIBUTES:
  	case KVM_CAP_PTP_KVM:
  	case KVM_CAP_ARM_SYSTEM_SUSPEND:
 +	case KVM_CAP_IRQFD_RESAMPLE:
+ 	case KVM_CAP_COUNTER_OFFSET:
  		r = 1;
  		break;
  	case KVM_CAP_SET_GUEST_DEBUG2:
@@@ -1440,7 -1475,28 +1476,27 @@@ static int kvm_vm_ioctl_set_device_addr
  	}
  }
  
+ static int kvm_vm_has_attr(struct kvm *kvm, struct kvm_device_attr *attr)
+ {
+ 	switch (attr->group) {
+ 	case KVM_ARM_VM_SMCCC_CTRL:
+ 		return kvm_vm_smccc_has_attr(kvm, attr);
+ 	default:
+ 		return -ENXIO;
+ 	}
+ }
+ 
+ static int kvm_vm_set_attr(struct kvm *kvm, struct kvm_device_attr *attr)
+ {
+ 	switch (attr->group) {
+ 	case KVM_ARM_VM_SMCCC_CTRL:
+ 		return kvm_vm_smccc_set_attr(kvm, attr);
+ 	default:
+ 		return -ENXIO;
+ 	}
+ }
+ 
 -long kvm_arch_vm_ioctl(struct file *filp,
 -		       unsigned int ioctl, unsigned long arg)
 +int kvm_arch_vm_ioctl(struct file *filp, unsigned int ioctl, unsigned long arg)
  {
  	struct kvm *kvm = filp->private_data;
  	void __user *argp = (void __user *)arg;

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

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/include/asm/kvm_host.h

between commit:

  2def950c63e3 ("KVM: arm64: Limit length in kvm_vm_ioctl_mte_copy_tags() to INT_MAX")

from the kvm tree and commit:

  30ec7997d175 ("KVM: arm64: timers: Allow userspace to set the global counter offset")

from the kvm-arm 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/arm64/include/asm/kvm_host.h
index 6f7b218a681f,a8e2c52b44aa..000000000000
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@@ -1005,8 -1020,10 +1020,10 @@@ int kvm_arm_vcpu_arch_get_attr(struct k
  int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
  			       struct kvm_device_attr *attr);
  
 -long kvm_vm_ioctl_mte_copy_tags(struct kvm *kvm,
 -				struct kvm_arm_copy_mte_tags *copy_tags);
 +int kvm_vm_ioctl_mte_copy_tags(struct kvm *kvm,
 +			       struct kvm_arm_copy_mte_tags *copy_tags);
+ int kvm_vm_ioctl_set_counter_offset(struct kvm *kvm,
+ 				    struct kvm_arm_counter_offset *offset);
  
  /* Guest/host FPSIMD coordination helpers */
  int kvm_arch_vcpu_run_map_fp(struct kvm_vcpu *vcpu);

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

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

[Marc Zyngier]

On Thu, 01 Dec 2022 02:16:23 +0000,
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Hi all,
> 
> Today's linux-next merge of the kvm-arm tree got a conflict in:
> 
>   tools/testing/selftests/kvm/include/perf_test_util.h
> 
> between commit:
> 
>   9fda6753c9dd ("KVM: selftests: Rename perf_test_util.[ch] to memstress.[ch]")
> 
> from the kvm tree and commit:
> 
>   9ec1eb1bccee ("KVM: selftests: Have perf_test_util signal when to stop vCPUs")
> 
> from the kvm-arm tree.
> 
> I fixed it up (I removed the file and applied the following patch) 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.
> 
> (this patch covered another occurrence fo the needed rename)

Huh, this is a lot of conflicts.

Paolo, do you have a stable branch I can pull in my tree to kill
those? Or do you want to deal with the conflicts yourself?

	M.

-- 
Without deviation from the norm, progress is not possible.

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

[Stephen Rothwell]

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

Hi all,

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

  tools/testing/selftests/kvm/include/perf_test_util.h

between commit:

  9fda6753c9dd ("KVM: selftests: Rename perf_test_util.[ch] to memstress.[ch]")

from the kvm tree and commit:

  9ec1eb1bccee ("KVM: selftests: Have perf_test_util signal when to stop vCPUs")

from the kvm-arm tree.

I fixed it up (I removed the file and applied the following patch) 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.

(this patch covered another occurrence fo the needed rename)

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 1 Dec 2022 12:19:45 +1100
Subject: [PATCH] fix up for rename of perf_test_args to memstress_args

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 tools/testing/selftests/kvm/access_tracking_perf_test.c       | 2 +-
 tools/testing/selftests/kvm/demand_paging_test.c              | 2 +-
 tools/testing/selftests/kvm/include/memstress.h               | 2 ++
 tools/testing/selftests/kvm/lib/memstress.c                   | 4 ++--
 .../testing/selftests/kvm/memslot_modification_stress_test.c  | 2 +-
 5 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/tools/testing/selftests/kvm/access_tracking_perf_test.c b/tools/testing/selftests/kvm/access_tracking_perf_test.c
index 2c9e0abcac94..57a16371e9c2 100644
--- a/tools/testing/selftests/kvm/access_tracking_perf_test.c
+++ b/tools/testing/selftests/kvm/access_tracking_perf_test.c
@@ -208,7 +208,7 @@ static bool spin_wait_for_next_iteration(int *current_iteration)
 	int last_iteration = *current_iteration;
 
 	do {
-		if (READ_ONCE(perf_test_args.stop_vcpus))
+		if (READ_ONCE(memstress_args.stop_vcpus))
 			return false;
 
 		*current_iteration = READ_ONCE(iteration);
diff --git a/tools/testing/selftests/kvm/demand_paging_test.c b/tools/testing/selftests/kvm/demand_paging_test.c
index f980ed8aeead..b0e1fc4de9e2 100644
--- a/tools/testing/selftests/kvm/demand_paging_test.c
+++ b/tools/testing/selftests/kvm/demand_paging_test.c
@@ -161,7 +161,7 @@ static void run_test(enum vm_guest_mode mode, void *arg)
 			vcpu_alias = addr_gpa2alias(vm, vcpu_args->gpa);
 
 			prefault_mem(vcpu_alias,
-				vcpu_args->pages * perf_test_args.guest_page_size);
+				vcpu_args->pages * memstress_args.guest_page_size);
 
 			/*
 			 * Set up user fault fd to handle demand paging
diff --git a/tools/testing/selftests/kvm/include/memstress.h b/tools/testing/selftests/kvm/include/memstress.h
index bbd2a302df10..4ae63963c14f 100644
--- a/tools/testing/selftests/kvm/include/memstress.h
+++ b/tools/testing/selftests/kvm/include/memstress.h
@@ -40,6 +40,8 @@ struct memstress_args {
 
 	/* Run vCPUs in L2 instead of L1, if the architecture supports it. */
 	bool nested;
+	/* Test is done, stop running vCPUs. */
+	bool stop_vcpus;
 	/* Randomize which pages are accessed by the guest. */
 	bool random_access;
 	/* True if all vCPUs are pinned to pCPUs */
diff --git a/tools/testing/selftests/kvm/lib/memstress.c b/tools/testing/selftests/kvm/lib/memstress.c
index 3742ce238129..5f1d3173c238 100644
--- a/tools/testing/selftests/kvm/lib/memstress.c
+++ b/tools/testing/selftests/kvm/lib/memstress.c
@@ -292,7 +292,7 @@ void memstress_start_vcpu_threads(int nr_vcpus,
 
 	vcpu_thread_fn = vcpu_fn;
 	WRITE_ONCE(all_vcpu_threads_running, false);
-	WRITE_ONCE(perf_test_args.stop_vcpus, false);
+	WRITE_ONCE(memstress_args.stop_vcpus, false);
 
 	for (i = 0; i < nr_vcpus; i++) {
 		struct vcpu_thread *vcpu = &vcpu_threads[i];
@@ -315,7 +315,7 @@ void memstress_join_vcpu_threads(int nr_vcpus)
 {
 	int i;
 
-	WRITE_ONCE(perf_test_args.stop_vcpus, true);
+	WRITE_ONCE(memstress_args.stop_vcpus, true);
 
 	for (i = 0; i < nr_vcpus; i++)
 		pthread_join(vcpu_threads[i].thread, NULL);
diff --git a/tools/testing/selftests/kvm/memslot_modification_stress_test.c b/tools/testing/selftests/kvm/memslot_modification_stress_test.c
index 431dbc47d345..9855c41ca811 100644
--- a/tools/testing/selftests/kvm/memslot_modification_stress_test.c
+++ b/tools/testing/selftests/kvm/memslot_modification_stress_test.c
@@ -43,7 +43,7 @@ static void vcpu_worker(struct memstress_vcpu_args *vcpu_args)
 	run = vcpu->run;
 
 	/* Let the guest access its memory until a stop signal is received */
-	while (!READ_ONCE(perf_test_args.stop_vcpus)) {
+	while (!READ_ONCE(memstress_args.stop_vcpus)) {
 		ret = _vcpu_run(vcpu);
 		TEST_ASSERT(ret == 0, "vcpu_run failed: %d\n", ret);
 
-- 
2.35.1

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

  tools/testing/selftests/kvm/memslot_perf_test.c

between commits:

  018ea2d71a43 ("KVM: selftests: Add atoi_paranoid() to catch errors missed by atoi()")
  dc88244bf548 ("KVM: selftests: Automatically do init_ucall() for non-barebones VMs")
  197ebb713ad0 ("KVM: selftests: move common startup logic to kvm_util.c")

from the kvm tree and commits:

  34396437b11f ("KVM: selftests: memslot_perf_test: Probe memory slots for once")
  8675c6f22698 ("KVM: selftests: memslot_perf_test: Support variable guest page size")
  a69170c65acd ("KVM: selftests: memslot_perf_test: Report optimal memory slots")

from the kvm-arm 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 tools/testing/selftests/kvm/memslot_perf_test.c
index 36b20abfb948,2ad40f7c9c08..000000000000
--- a/tools/testing/selftests/kvm/memslot_perf_test.c
+++ b/tools/testing/selftests/kvm/memslot_perf_test.c
@@@ -252,23 -284,22 +284,21 @@@ static bool prepare_vm(struct vm_data *
  	struct timespec tstart;
  	struct sync_area *sync;
  
- 	max_mem_slots = kvm_check_cap(KVM_CAP_NR_MEMSLOTS);
- 	TEST_ASSERT(max_mem_slots > 1,
- 		    "KVM_CAP_NR_MEMSLOTS should be greater than 1");
- 	TEST_ASSERT(nslots > 1 || nslots == -1,
- 		    "Slot count cap should be greater than 1");
- 	if (nslots != -1)
- 		max_mem_slots = min(max_mem_slots, (uint32_t)nslots);
- 	pr_info_v("Allowed number of memory slots: %"PRIu32"\n", max_mem_slots);
+ 	host_page_size = getpagesize();
+ 	guest_page_size = vm_guest_mode_params[VM_MODE_DEFAULT].page_size;
+ 	mempages = mem_size / guest_page_size;
  
- 	TEST_ASSERT(mempages > 1,
- 		    "Can't test without any memory");
+ 	data->vm = __vm_create_with_one_vcpu(&data->vcpu, mempages, guest_code);
 -	ucall_init(data->vm, NULL);
+ 	TEST_ASSERT(data->vm->page_size == guest_page_size, "Invalid VM page size");
  
  	data->npages = mempages;
- 	data->nslots = max_mem_slots - 1;
- 	data->pages_per_slot = mempages / data->nslots;
- 	if (!data->pages_per_slot) {
- 		*maxslots = mempages + 1;
+ 	TEST_ASSERT(data->npages > 1, "Can't test without any memory");
+ 	data->nslots = nslots;
+ 	data->pages_per_slot = data->npages / data->nslots;
+ 	rempages = data->npages % data->nslots;
+ 	if (!check_slot_pages(host_page_size, guest_page_size,
+ 			      data->pages_per_slot, rempages)) {
+ 		*maxslots = get_max_slots(data, host_page_size);
  		return false;
  	}
  
@@@ -884,9 -966,9 +965,9 @@@ static bool parse_args(int argc, char *
  			map_unmap_verify = true;
  			break;
  		case 's':
 -			targs->nslots = atoi(optarg);
 +			targs->nslots = atoi_paranoid(optarg);
- 			if (targs->nslots <= 0 && targs->nslots != -1) {
- 				pr_info("Slot count cap has to be positive or -1 for no cap\n");
+ 			if (targs->nslots <= 1 && targs->nslots != -1) {
+ 				pr_info("Slot count cap must be larger than 1 or -1 for no cap\n");
  				return false;
  			}
  			break;
@@@ -994,6 -1103,12 +1090,9 @@@ int main(int argc, char *argv[]
  	struct test_result rbestslottime;
  	int tctr;
  
 -	/* Tell stdout not to buffer its content */
 -	setbuf(stdout, NULL);
 -
+ 	if (!check_memory_sizes())
+ 		return -1;
+ 
  	if (!parse_args(argc, argv, &targs))
  		return -1;
  

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

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the kvm-arm tree got conflicts in:

  tools/testing/selftests/kvm/access_tracking_perf_test.c
  tools/testing/selftests/kvm/memslot_modification_stress_test.c

between commit:

  7812d80c0f89 ("KVM: selftests: Rename perf_test_util symbols to memstress")

from the kvm tree and commit:

  9ec1eb1bccee ("KVM: selftests: Have perf_test_util signal when to stop vCPUs")

from the kvm-arm 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 tools/testing/selftests/kvm/access_tracking_perf_test.c
index 02d3587cab0a,942370d57392..000000000000
--- a/tools/testing/selftests/kvm/access_tracking_perf_test.c
+++ b/tools/testing/selftests/kvm/access_tracking_perf_test.c
@@@ -321,11 -318,8 +318,8 @@@ static void run_test(enum vm_guest_mod
  	mark_memory_idle(vm, nr_vcpus);
  	access_memory(vm, nr_vcpus, ACCESS_READ, "Reading from idle memory");
  
- 	/* Set done to signal the vCPU threads to exit */
- 	done = true;
- 
 -	perf_test_join_vcpu_threads(nr_vcpus);
 -	perf_test_destroy_vm(vm);
 +	memstress_join_vcpu_threads(nr_vcpus);
 +	memstress_destroy_vm(vm);
  }
  
  static void help(char *name)
diff --cc tools/testing/selftests/kvm/memslot_modification_stress_test.c
index d07e921bfcc5,3a5e4518307c..000000000000
--- a/tools/testing/selftests/kvm/memslot_modification_stress_test.c
+++ b/tools/testing/selftests/kvm/memslot_modification_stress_test.c
@@@ -34,9 -34,7 +34,7 @@@
  static int nr_vcpus = 1;
  static uint64_t guest_percpu_mem_size = DEFAULT_PER_VCPU_MEM_SIZE;
  
- static bool run_vcpus = true;
- 
 -static void vcpu_worker(struct perf_test_vcpu_args *vcpu_args)
 +static void vcpu_worker(struct memstress_vcpu_args *vcpu_args)
  {
  	struct kvm_vcpu *vcpu = vcpu_args->vcpu;
  	struct kvm_run *run;
@@@ -107,14 -105,13 +105,12 @@@ static void run_test(enum vm_guest_mod
  
  	pr_info("Started all vCPUs\n");
  
 -	add_remove_memslot(vm, p->memslot_modification_delay,
 -			   p->nr_memslot_modifications);
 +	add_remove_memslot(vm, p->delay, p->nr_iterations);
  
- 	run_vcpus = false;
- 
 -	perf_test_join_vcpu_threads(nr_vcpus);
 +	memstress_join_vcpu_threads(nr_vcpus);
  	pr_info("All vCPU threads joined\n");
  
 -	perf_test_destroy_vm(vm);
 +	memstress_destroy_vm(vm);
  }
  
  static void help(char *name)

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

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the kvm-arm tree got conflicts in:

  tools/testing/selftests/kvm/Makefile
  tools/testing/selftests/kvm/demand_paging_test.c

between commit:

  7812d80c0f89 ("KVM: selftests: Rename perf_test_util symbols to memstress")
  7046638192d5 ("KVM: selftests: Consolidate common code for populating ucall struct")

from the kvm tree and commit:

  a93871d0ea9f ("KVM: selftests: Add a userfaultfd library")

from the kvm-arm 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 tools/testing/selftests/kvm/Makefile
index 2275ba861e0e,1d85b8e218a0..000000000000
--- a/tools/testing/selftests/kvm/Makefile
+++ b/tools/testing/selftests/kvm/Makefile
@@@ -47,7 -47,7 +47,8 @@@ LIBKVM += lib/memstress.
  LIBKVM += lib/rbtree.c
  LIBKVM += lib/sparsebit.c
  LIBKVM += lib/test_util.c
 +LIBKVM += lib/ucall_common.c
+ LIBKVM += lib/userfaultfd_util.c
  
  LIBKVM_STRING += lib/string_override.c
  
diff --cc tools/testing/selftests/kvm/demand_paging_test.c
index 3a977ddf07b2,8e1fe4ffcccd..000000000000
--- a/tools/testing/selftests/kvm/demand_paging_test.c
+++ b/tools/testing/selftests/kvm/demand_paging_test.c
@@@ -20,8 -20,9 +20,9 @@@
  
  #include "kvm_util.h"
  #include "test_util.h"
 -#include "perf_test_util.h"
 +#include "memstress.h"
  #include "guest_modes.h"
+ #include "userfaultfd_util.h"
  
  #ifdef __NR_userfaultfd
  
@@@ -270,22 -129,13 +129,13 @@@ static void prefault_mem(void *alias, u
  static void run_test(enum vm_guest_mode mode, void *arg)
  {
  	struct test_params *p = arg;
- 	pthread_t *uffd_handler_threads = NULL;
- 	struct uffd_handler_args *uffd_args = NULL;
+ 	struct uffd_desc **uffd_descs = NULL;
  	struct timespec start;
  	struct timespec ts_diff;
- 	int *pipefds = NULL;
  	struct kvm_vm *vm;
- 	int r, i;
+ 	int i;
  
 -	vm = perf_test_create_vm(mode, nr_vcpus, guest_percpu_mem_size, 1,
 +	vm = memstress_create_vm(mode, nr_vcpus, guest_percpu_mem_size, 1,
  				 p->src_type, p->partition_vcpu_memory_access);
  
  	demand_paging_size = get_backing_src_pagesz(p->src_type);
@@@ -296,18 -146,11 +146,11 @@@
  	memset(guest_data_prototype, 0xAB, demand_paging_size);
  
  	if (p->uffd_mode) {
- 		uffd_handler_threads =
- 			malloc(nr_vcpus * sizeof(*uffd_handler_threads));
- 		TEST_ASSERT(uffd_handler_threads, "Memory allocation failed");
- 
- 		uffd_args = malloc(nr_vcpus * sizeof(*uffd_args));
- 		TEST_ASSERT(uffd_args, "Memory allocation failed");
- 
- 		pipefds = malloc(sizeof(int) * nr_vcpus * 2);
- 		TEST_ASSERT(pipefds, "Unable to allocate memory for pipefd");
+ 		uffd_descs = malloc(nr_vcpus * sizeof(struct uffd_desc *));
+ 		TEST_ASSERT(uffd_descs, "Memory allocation failed");
  
  		for (i = 0; i < nr_vcpus; i++) {
 -			struct perf_test_vcpu_args *vcpu_args;
 +			struct memstress_vcpu_args *vcpu_args;
  			void *vcpu_hva;
  			void *vcpu_alias;
  
@@@ -321,15 -167,10 +167,10 @@@
  			 * Set up user fault fd to handle demand paging
  			 * requests.
  			 */
- 			r = pipe2(&pipefds[i * 2],
- 				  O_CLOEXEC | O_NONBLOCK);
- 			TEST_ASSERT(!r, "Failed to set up pipefd");
- 
- 			setup_demand_paging(vm, &uffd_handler_threads[i],
- 					    pipefds[i * 2], p->uffd_mode,
- 					    p->uffd_delay, &uffd_args[i],
- 					    vcpu_hva, vcpu_alias,
- 					    vcpu_args->pages * memstress_args.guest_page_size);
+ 			uffd_descs[i] = uffd_setup_demand_paging(
+ 				p->uffd_mode, p->uffd_delay, vcpu_hva,
 -				vcpu_args->pages * perf_test_args.guest_page_size,
++				vcpu_args->pages * memstress_args.guest_page_size,
+ 				&handle_uffd_page_request);
  		}
  	}
  
@@@ -358,17 -193,14 +193,14 @@@
  	pr_info("Total guest execution time: %ld.%.9lds\n",
  		ts_diff.tv_sec, ts_diff.tv_nsec);
  	pr_info("Overall demand paging rate: %f pgs/sec\n",
 -		perf_test_args.vcpu_args[0].pages * nr_vcpus /
 +		memstress_args.vcpu_args[0].pages * nr_vcpus /
  		((double)ts_diff.tv_sec + (double)ts_diff.tv_nsec / 100000000.0));
  
 -	perf_test_destroy_vm(vm);
 +	memstress_destroy_vm(vm);
  
  	free(guest_data_prototype);
- 	if (p->uffd_mode) {
- 		free(uffd_handler_threads);
- 		free(uffd_args);
- 		free(pipefds);
- 	}
+ 	if (p->uffd_mode)
+ 		free(uffd_descs);
  }
  
  static void help(char *name)

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

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

[Stephen Rothwell]

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

Hi all,

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

  tools/testing/selftests/kvm/aarch64/vgic_init.c

between commits:

  98f94ce42ac6 ("KVM: selftests: Move KVM_CREATE_DEVICE_TEST code to separate helper")
  7ed397d107d4 ("KVM: selftests: Add TEST_REQUIRE macros to reduce skipping copy+paste")

from the kvm tree and commit:

  6a4f7fcd7504 ("KVM: arm64: selftests: Add support for GICv2 on v3")

from the kvm-arm tree.

I fixed it up (I think, 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 tools/testing/selftests/kvm/aarch64/vgic_init.c
index e8cab9840aa3,21ba4002fc18..000000000000
--- a/tools/testing/selftests/kvm/aarch64/vgic_init.c
+++ b/tools/testing/selftests/kvm/aarch64/vgic_init.c
@@@ -661,9 -668,9 +661,9 @@@ int test_kvm_device(uint32_t gic_dev_ty
  	other = VGIC_DEV_IS_V2(gic_dev_type) ? KVM_DEV_TYPE_ARM_VGIC_V3
  					     : KVM_DEV_TYPE_ARM_VGIC_V2;
  
 -	if (!_kvm_create_device(v.vm, other, true, &fd)) {
 -		ret = _kvm_create_device(v.vm, other, false, &fd);
 +	if (!__kvm_test_create_device(v.vm, other)) {
 +		ret = __kvm_test_create_device(v.vm, other);
- 		TEST_ASSERT(ret && errno == EINVAL,
+ 		TEST_ASSERT(ret && (errno == EINVAL || errno == EEXIST),
  				"create GIC device while other version exists");
  	}
  
@@@ -703,9 -711,15 +704,13 @@@ int main(int ac, char **av
  	}
  
  	ret = test_kvm_device(KVM_DEV_TYPE_ARM_VGIC_V2);
- 	__TEST_REQUIRE(!ret, "No GICv2 nor GICv3 support");
+ 	if (!ret) {
+ 		pr_info("Running GIC_v2 tests.\n");
+ 		run_tests(KVM_DEV_TYPE_ARM_VGIC_V2);
+ 		cnt_impl++;
+ 	}
+ 
 -	if (!cnt_impl) {
 -		print_skip("No GICv2 nor GICv3 support");
 -		exit(KSFT_SKIP);
 -	}
++	__TEST_REQUIRE(!cnt_impl, "No GICv2 nor GICv3 support");
 +
- 	pr_info("Running GIC_v2 tests.\n");
- 	run_tests(KVM_DEV_TYPE_ARM_VGIC_V2);
  	return 0;
  }

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

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the kvm-arm tree got conflicts in:

  include/uapi/linux/kvm.h
  Documentation/virt/kvm/api.rst

between commits:

  c24a950ec7d6 ("KVM, SEV: Add KVM_EXIT_SHUTDOWN metadata for SEV-ES")
  71d7c575a673 ("Merge branch 'kvm-fixes-for-5.18-rc5' into HEAD")

from the kvm tree and commits:

  7b33a09d036f ("KVM: arm64: Add support for userspace to suspend a vCPU")
  bfbab4456877 ("KVM: arm64: Implement PSCI SYSTEM_SUSPEND")

from the kvm-arm 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 Documentation/virt/kvm/api.rst
index 2325b703a1ea,cbea3983f47b..000000000000
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@@ -6090,7 -6032,8 +6137,9 @@@ should put the acknowledged interrupt v
    #define KVM_SYSTEM_EVENT_SHUTDOWN       1
    #define KVM_SYSTEM_EVENT_RESET          2
    #define KVM_SYSTEM_EVENT_CRASH          3
 -  #define KVM_SYSTEM_EVENT_WAKEUP         4
 -  #define KVM_SYSTEM_EVENT_SUSPEND        5
 +  #define KVM_SYSTEM_EVENT_SEV_TERM       4
++  #define KVM_SYSTEM_EVENT_WAKEUP         5
++  #define KVM_SYSTEM_EVENT_SUSPEND        6
  			__u32 type;
                          __u32 ndata;
                          __u64 data[16];
@@@ -6115,8 -6058,37 +6164,39 @@@ Valid values for 'type' are
     has requested a crash condition maintenance. Userspace can choose
     to ignore the request, or to gather VM memory core dump and/or
     reset/shutdown of the VM.
 + - KVM_SYSTEM_EVENT_SEV_TERM -- an AMD SEV guest requested termination.
 +   The guest physical address of the guest's GHCB is stored in `data[0]`.
+  - KVM_SYSTEM_EVENT_WAKEUP -- the exiting vCPU is in a suspended state and
+    KVM has recognized a wakeup event. Userspace may honor this event by
+    marking the exiting vCPU as runnable, or deny it and call KVM_RUN again.
+  - KVM_SYSTEM_EVENT_SUSPEND -- the guest has requested a suspension of
+    the VM.
+ 
+ For arm/arm64:
+ ^^^^^^^^^^^^^^
+ 
+    KVM_SYSTEM_EVENT_SUSPEND exits are enabled with the
+    KVM_CAP_ARM_SYSTEM_SUSPEND VM capability. If a guest invokes the PSCI
+    SYSTEM_SUSPEND function, KVM will exit to userspace with this event
+    type.
+ 
+    It is the sole responsibility of userspace to implement the PSCI
+    SYSTEM_SUSPEND call according to ARM DEN0022D.b 5.19 "SYSTEM_SUSPEND".
+    KVM does not change the vCPU's state before exiting to userspace, so
+    the call parameters are left in-place in the vCPU registers.
+ 
+    Userspace is _required_ to take action for such an exit. It must
+    either:
+ 
+     - Honor the guest request to suspend the VM. Userspace can request
+       in-kernel emulation of suspension by setting the calling vCPU's
+       state to KVM_MP_STATE_SUSPENDED. Userspace must configure the vCPU's
+       state according to the parameters passed to the PSCI function when
+       the calling vCPU is resumed. See ARM DEN0022D.b 5.19.1 "Intended use"
+       for details on the function parameters.
+ 
+     - Deny the guest request to suspend the VM. See ARM DEN0022D.b 5.19.2
+       "Caller responsibilities" for possible return values.
  
  If KVM_CAP_SYSTEM_EVENT_DATA is present, the 'data' field can contain
  architecture specific information for the system-level event.  Only
diff --cc include/uapi/linux/kvm.h
index e10d131edd80,32c56384fd08..000000000000
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@@ -444,7 -444,8 +444,9 @@@ struct kvm_run 
  #define KVM_SYSTEM_EVENT_SHUTDOWN       1
  #define KVM_SYSTEM_EVENT_RESET          2
  #define KVM_SYSTEM_EVENT_CRASH          3
 -#define KVM_SYSTEM_EVENT_WAKEUP         4
 -#define KVM_SYSTEM_EVENT_SUSPEND        5
 +#define KVM_SYSTEM_EVENT_SEV_TERM       4
++#define KVM_SYSTEM_EVENT_WAKEUP         5
++#define KVM_SYSTEM_EVENT_SUSPEND        6
  			__u32 type;
  			__u32 ndata;
  			union {
@@@ -1151,8 -1153,9 +1154,9 @@@ struct kvm_ppc_resize_hpt 
  #define KVM_CAP_S390_MEM_OP_EXTENSION 211
  #define KVM_CAP_PMU_CAPABILITY 212
  #define KVM_CAP_DISABLE_QUIRKS2 213
 -/* #define KVM_CAP_VM_TSC_CONTROL 214 */
 +#define KVM_CAP_VM_TSC_CONTROL 214
  #define KVM_CAP_SYSTEM_EVENT_DATA 215
+ #define KVM_CAP_ARM_SYSTEM_SUSPEND 216
  
  #ifdef KVM_CAP_IRQ_ROUTING
  

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

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/kvm/arm.c

between commit:

  27592ae8dbe4 ("KVM: Move wiping of the kvm->vcpus array to common code")

from the kvm tree and commit:

  52b28657ebd7 ("KVM: arm64: pkvm: Unshare guest structs during teardown")

from the kvm-arm 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/arm64/kvm/arm.c
index 7385bbdfdc42,6057f3c5aafe..000000000000
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@@ -179,7 -181,15 +179,9 @@@ void kvm_arch_destroy_vm(struct kvm *kv
  
  	kvm_vgic_destroy(kvm);
  
 -	for (i = 0; i < KVM_MAX_VCPUS; ++i) {
 -		if (kvm->vcpus[i]) {
 -			kvm_vcpu_destroy(kvm->vcpus[i]);
 -			kvm->vcpus[i] = NULL;
 -		}
 -	}
 -	atomic_set(&kvm->online_vcpus, 0);
 +	kvm_destroy_vcpus(kvm);
+ 
+ 	kvm_unshare_hyp(kvm, kvm + 1);
  }
  
  int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)

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

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

[broonie]

Hi all,

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

  arch/arm64/kvm/arm.c

between commit:

  6109c5a6ab7f3 ("KVM: arm64: Move vGIC v4 handling for WFI out arch callback hook")

from the kvm tree and commit:

  b5aa368abfbf4 ("KVM: arm64: Merge kvm_arch_vcpu_run_pid_change() and kvm_vcpu_first_run_init()")

from the kvm-arm tree.

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

diff --cc arch/arm64/kvm/arm.c
index 7385bbdfdc42c,9b745d2bc89aa..0000000000000
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@@ -661,44 -698,6 +680,39 @@@ static void vcpu_req_sleep(struct kvm_v
  	smp_rmb();
  }
  
 +/**
 + * kvm_vcpu_wfi - emulate Wait-For-Interrupt behavior
 + * @vcpu:	The VCPU pointer
 + *
 + * Suspend execution of a vCPU until a valid wake event is detected, i.e. until
 + * the vCPU is runnable.  The vCPU may or may not be scheduled out, depending
 + * on when a wake event arrives, e.g. there may already be a pending wake event.
 + */
 +void kvm_vcpu_wfi(struct kvm_vcpu *vcpu)
 +{
 +	/*
 +	 * Sync back the state of the GIC CPU interface so that we have
 +	 * the latest PMR and group enables. This ensures that
 +	 * kvm_arch_vcpu_runnable has up-to-date data to decide whether
 +	 * we have pending interrupts, e.g. when determining if the
 +	 * vCPU should block.
 +	 *
 +	 * For the same reason, we want to tell GICv4 that we need
 +	 * doorbells to be signalled, should an interrupt become pending.
 +	 */
 +	preempt_disable();
 +	kvm_vgic_vmcr_sync(vcpu);
 +	vgic_v4_put(vcpu, true);
 +	preempt_enable();
 +
 +	kvm_vcpu_halt(vcpu);
 +	kvm_clear_request(KVM_REQ_UNHALT, vcpu);
 +
 +	preempt_disable();
 +	vgic_v4_load(vcpu);
 +	preempt_enable();
 +}
 +
- static int kvm_vcpu_initialized(struct kvm_vcpu *vcpu)
- {
- 	return vcpu->arch.target >= 0;
- }
- 
  static void check_vcpu_requests(struct kvm_vcpu *vcpu)
  {
  	if (kvm_request_pending(vcpu)) {

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

[Stephen Rothwell]

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

Hi all,

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

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

between commit:

  ef6a74b2e55e ("KVM: sefltests: Add x86-64 test to verify MMU reacts to CPUID updates")

from the kvm tree and commit:

  75275d7fbef4 ("KVM: selftests: Introduce UCALL_UNHANDLED for unhandled vector reporting")

from the kvm-arm 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 tools/testing/selftests/kvm/include/x86_64/processor.h
index 6d27a5435971,92a62c6999bc..000000000000
--- a/tools/testing/selftests/kvm/include/x86_64/processor.h
+++ b/tools/testing/selftests/kvm/include/x86_64/processor.h
@@@ -55,11 -53,6 +55,9 @@@
  #define CPUID_PKU		(1ul << 3)
  #define CPUID_LA57		(1ul << 16)
  
 +/* CPUID.0x8000_0001.EDX */
 +#define CPUID_GBPAGES		(1ul << 26)
 +
- #define UNEXPECTED_VECTOR_PORT 0xfff0u
- 
  /* General Registers in 64-Bit Mode */
  struct gpr64_regs {
  	u64 rax;
@@@ -396,13 -389,9 +394,13 @@@ struct ex_regs 
  
  void vm_init_descriptor_tables(struct kvm_vm *vm);
  void vcpu_init_descriptor_tables(struct kvm_vm *vm, uint32_t vcpuid);
- void vm_handle_exception(struct kvm_vm *vm, int vector,
+ void vm_install_exception_handler(struct kvm_vm *vm, int vector,
  			void (*handler)(struct ex_regs *));
  
 +uint64_t vm_get_page_table_entry(struct kvm_vm *vm, int vcpuid, uint64_t vaddr);
 +void vm_set_page_table_entry(struct kvm_vm *vm, int vcpuid, uint64_t vaddr,
 +			     uint64_t pte);
 +
  /*
   * set_cpuid() - overwrites a matching cpuid entry with the provided value.
   *		 matches based on ent->function && ent->index. returns true

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

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

[Stephen Rothwell]

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

Hi all,

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

  include/uapi/linux/kvm.h

between commits:

  cb082bfab59a ("KVM: stats: Add fd-based API to read binary stats data")
  19238e75bd8e ("kvm: x86: Allow userspace to handle emulation errors")

from the kvm tree and commit:

  ea7fc1bb1cd1 ("KVM: arm64: Introduce MTE VM feature")

from the kvm-arm 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 include/uapi/linux/kvm.h
index 68c9e6d8bbda,da1edd2b4046..000000000000
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@@ -1105,12 -1083,7 +1105,13 @@@ struct kvm_ppc_resize_hpt 
  #define KVM_CAP_SGX_ATTRIBUTE 196
  #define KVM_CAP_VM_COPY_ENC_CONTEXT_FROM 197
  #define KVM_CAP_PTP_KVM 198
 -#define KVM_CAP_ARM_MTE 199
 +#define KVM_CAP_HYPERV_ENFORCE_CPUID 199
 +#define KVM_CAP_SREGS2 200
 +#define KVM_CAP_EXIT_HYPERCALL 201
 +#define KVM_CAP_PPC_RPT_INVALIDATE 202
 +#define KVM_CAP_BINARY_STATS_FD 203
 +#define KVM_CAP_EXIT_ON_EMULATION_FAILURE 204
++#define KVM_CAP_ARM_MTE 205
  
  #ifdef KVM_CAP_IRQ_ROUTING
  

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

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

[Stephen Rothwell]

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

Hi all,

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

  Documentation/virt/kvm/api.rst

between commit:

  fdc09ddd4064 ("KVM: stats: Add documentation for binary statistics interface")

from the kvm tree and commit:

  04c02c201d7e ("KVM: arm64: Document MTE capability and ioctl")

from the kvm-arm 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 Documentation/virt/kvm/api.rst
index aba27461edec,97661a97943f..000000000000
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@@ -5039,224 -5034,43 +5039,260 @@@ see KVM_XEN_VCPU_SET_ATTR above
  The KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADJUST type may not be used
  with the KVM_XEN_VCPU_GET_ATTR ioctl.
  
+ 4.130 KVM_ARM_MTE_COPY_TAGS
+ ---------------------------
+ 
+ :Capability: KVM_CAP_ARM_MTE
+ :Architectures: arm64
+ :Type: vm ioctl
+ :Parameters: struct kvm_arm_copy_mte_tags
+ :Returns: number of bytes copied, < 0 on error (-EINVAL for incorrect
+           arguments, -EFAULT if memory cannot be accessed).
+ 
+ ::
+ 
+   struct kvm_arm_copy_mte_tags {
+ 	__u64 guest_ipa;
+ 	__u64 length;
+ 	void __user *addr;
+ 	__u64 flags;
+ 	__u64 reserved[2];
+   };
+ 
+ Copies Memory Tagging Extension (MTE) tags to/from guest tag memory. The
+ ``guest_ipa`` and ``length`` fields must be ``PAGE_SIZE`` aligned. The ``addr``
+ field must point to a buffer which the tags will be copied to or from.
+ 
+ ``flags`` specifies the direction of copy, either ``KVM_ARM_TAGS_TO_GUEST`` or
+ ``KVM_ARM_TAGS_FROM_GUEST``.
+ 
+ The size of the buffer to store the tags is ``(length / 16)`` bytes
+ (granules in MTE are 16 bytes long). Each byte contains a single tag
+ value. This matches the format of ``PTRACE_PEEKMTETAGS`` and
+ ``PTRACE_POKEMTETAGS``.
+ 
+ If an error occurs before any data is copied then a negative error code is
+ returned. If some tags have been copied before an error occurs then the number
+ of bytes successfully copied is returned. If the call completes successfully
+ then ``length`` is returned.
  
 +4.131 KVM_GET_SREGS2
 +------------------
 +
 +:Capability: KVM_CAP_SREGS2
 +:Architectures: x86
 +:Type: vcpu ioctl
 +:Parameters: struct kvm_sregs2 (out)
 +:Returns: 0 on success, -1 on error
 +
 +Reads special registers from the vcpu.
 +This ioctl (when supported) replaces the KVM_GET_SREGS.
 +
 +::
 +
 +struct kvm_sregs2 {
 +	/* out (KVM_GET_SREGS2) / in (KVM_SET_SREGS2) */
 +	struct kvm_segment cs, ds, es, fs, gs, ss;
 +	struct kvm_segment tr, ldt;
 +	struct kvm_dtable gdt, idt;
 +	__u64 cr0, cr2, cr3, cr4, cr8;
 +	__u64 efer;
 +	__u64 apic_base;
 +	__u64 flags;
 +	__u64 pdptrs[4];
 +};
 +
 +flags values for ``kvm_sregs2``:
 +
 +``KVM_SREGS2_FLAGS_PDPTRS_VALID``
 +
 +  Indicates thats the struct contain valid PDPTR values.
 +
 +
 +4.132 KVM_SET_SREGS2
 +------------------
 +
 +:Capability: KVM_CAP_SREGS2
 +:Architectures: x86
 +:Type: vcpu ioctl
 +:Parameters: struct kvm_sregs2 (in)
 +:Returns: 0 on success, -1 on error
 +
 +Writes special registers into the vcpu.
 +See KVM_GET_SREGS2 for the data structures.
 +This ioctl (when supported) replaces the KVM_SET_SREGS.
 +
 +4.133 KVM_GET_STATS_FD
 +----------------------
 +
 +:Capability: KVM_CAP_STATS_BINARY_FD
 +:Architectures: all
 +:Type: vm ioctl, vcpu ioctl
 +:Parameters: none
 +:Returns: statistics file descriptor on success, < 0 on error
 +
 +Errors:
 +
 +  ======     ======================================================
 +  ENOMEM     if the fd could not be created due to lack of memory
 +  EMFILE     if the number of opened files exceeds the limit
 +  ======     ======================================================
 +
 +The returned file descriptor can be used to read VM/vCPU statistics data in
 +binary format. The data in the file descriptor consists of four blocks
 +organized as follows:
 +
 ++-------------+
 +|   Header    |
 ++-------------+
 +|  id string  |
 ++-------------+
 +| Descriptors |
 ++-------------+
 +| Stats Data  |
 ++-------------+
 +
 +Apart from the header starting at offset 0, please be aware that it is
 +not guaranteed that the four blocks are adjacent or in the above order;
 +the offsets of the id, descriptors and data blocks are found in the
 +header.  However, all four blocks are aligned to 64 bit offsets in the
 +file and they do not overlap.
 +
 +All blocks except the data block are immutable.  Userspace can read them
 +only one time after retrieving the file descriptor, and then use ``pread`` or
 +``lseek`` to read the statistics repeatedly.
 +
 +All data is in system endianness.
 +
 +The format of the header is as follows::
 +
 +	struct kvm_stats_header {
 +		__u32 flags;
 +		__u32 name_size;
 +		__u32 num_desc;
 +		__u32 id_offset;
 +		__u32 desc_offset;
 +		__u32 data_offset;
 +	};
 +
 +The ``flags`` field is not used at the moment. It is always read as 0.
 +
 +The ``name_size`` field is the size (in byte) of the statistics name string
 +(including trailing '\0') which is contained in the "id string" block and
 +appended at the end of every descriptor.
 +
 +The ``num_desc`` field is the number of descriptors that are included in the
 +descriptor block.  (The actual number of values in the data block may be
 +larger, since each descriptor may comprise more than one value).
 +
 +The ``id_offset`` field is the offset of the id string from the start of the
 +file indicated by the file descriptor. It is a multiple of 8.
 +
 +The ``desc_offset`` field is the offset of the Descriptors block from the start
 +of the file indicated by the file descriptor. It is a multiple of 8.
 +
 +The ``data_offset`` field is the offset of the Stats Data block from the start
 +of the file indicated by the file descriptor. It is a multiple of 8.
 +
 +The id string block contains a string which identifies the file descriptor on
 +which KVM_GET_STATS_FD was invoked.  The size of the block, including the
 +trailing ``'\0'``, is indicated by the ``name_size`` field in the header.
 +
 +The descriptors block is only needed to be read once for the lifetime of the
 +file descriptor contains a sequence of ``struct kvm_stats_desc``, each followed
 +by a string of size ``name_size``.
 +
 +	#define KVM_STATS_TYPE_SHIFT		0
 +	#define KVM_STATS_TYPE_MASK		(0xF << KVM_STATS_TYPE_SHIFT)
 +	#define KVM_STATS_TYPE_CUMULATIVE	(0x0 << KVM_STATS_TYPE_SHIFT)
 +	#define KVM_STATS_TYPE_INSTANT		(0x1 << KVM_STATS_TYPE_SHIFT)
 +	#define KVM_STATS_TYPE_PEAK		(0x2 << KVM_STATS_TYPE_SHIFT)
 +
 +	#define KVM_STATS_UNIT_SHIFT		4
 +	#define KVM_STATS_UNIT_MASK		(0xF << KVM_STATS_UNIT_SHIFT)
 +	#define KVM_STATS_UNIT_NONE		(0x0 << KVM_STATS_UNIT_SHIFT)
 +	#define KVM_STATS_UNIT_BYTES		(0x1 << KVM_STATS_UNIT_SHIFT)
 +	#define KVM_STATS_UNIT_SECONDS		(0x2 << KVM_STATS_UNIT_SHIFT)
 +	#define KVM_STATS_UNIT_CYCLES		(0x3 << KVM_STATS_UNIT_SHIFT)
 +
 +	#define KVM_STATS_BASE_SHIFT		8
 +	#define KVM_STATS_BASE_MASK		(0xF << KVM_STATS_BASE_SHIFT)
 +	#define KVM_STATS_BASE_POW10		(0x0 << KVM_STATS_BASE_SHIFT)
 +	#define KVM_STATS_BASE_POW2		(0x1 << KVM_STATS_BASE_SHIFT)
 +
 +	struct kvm_stats_desc {
 +		__u32 flags;
 +		__s16 exponent;
 +		__u16 size;
 +		__u32 offset;
 +		__u32 unused;
 +		char name[];
 +	};
 +
 +The ``flags`` field contains the type and unit of the statistics data described
 +by this descriptor. Its endianness is CPU native.
 +The following flags are supported:
 +
 +Bits 0-3 of ``flags`` encode the type:
 +  * ``KVM_STATS_TYPE_CUMULATIVE``
 +    The statistics data is cumulative. The value of data can only be increased.
 +    Most of the counters used in KVM are of this type.
 +    The corresponding ``size`` field for this type is always 1.
 +    All cumulative statistics data are read/write.
 +  * ``KVM_STATS_TYPE_INSTANT``
 +    The statistics data is instantaneous. Its value can be increased or
 +    decreased. This type is usually used as a measurement of some resources,
 +    like the number of dirty pages, the number of large pages, etc.
 +    All instant statistics are read only.
 +    The corresponding ``size`` field for this type is always 1.
 +  * ``KVM_STATS_TYPE_PEAK``
 +    The statistics data is peak. The value of data can only be increased, and
 +    represents a peak value for a measurement, for example the maximum number
 +    of items in a hash table bucket, the longest time waited and so on.
 +    The corresponding ``size`` field for this type is always 1.
 +
 +Bits 4-7 of ``flags`` encode the unit:
 +  * ``KVM_STATS_UNIT_NONE``
 +    There is no unit for the value of statistics data. This usually means that
 +    the value is a simple counter of an event.
 +  * ``KVM_STATS_UNIT_BYTES``
 +    It indicates that the statistics data is used to measure memory size, in the
 +    unit of Byte, KiByte, MiByte, GiByte, etc. The unit of the data is
 +    determined by the ``exponent`` field in the descriptor.
 +  * ``KVM_STATS_UNIT_SECONDS``
 +    It indicates that the statistics data is used to measure time or latency.
 +  * ``KVM_STATS_UNIT_CYCLES``
 +    It indicates that the statistics data is used to measure CPU clock cycles.
 +
 +Bits 8-11 of ``flags``, together with ``exponent``, encode the scale of the
 +unit:
 +  * ``KVM_STATS_BASE_POW10``
 +    The scale is based on power of 10. It is used for measurement of time and
 +    CPU clock cycles.  For example, an exponent of -9 can be used with
 +    ``KVM_STATS_UNIT_SECONDS`` to express that the unit is nanoseconds.
 +  * ``KVM_STATS_BASE_POW2``
 +    The scale is based on power of 2. It is used for measurement of memory size.
 +    For example, an exponent of 20 can be used with ``KVM_STATS_UNIT_BYTES`` to
 +    express that the unit is MiB.
 +
 +The ``size`` field is the number of values of this statistics data. Its
 +value is usually 1 for most of simple statistics. 1 means it contains an
 +unsigned 64bit data.
 +
 +The ``offset`` field is the offset from the start of Data Block to the start of
 +the corresponding statistics data.
 +
 +The ``unused`` field is reserved for future support for other types of
 +statistics data, like log/linear histogram. Its value is always 0 for the types
 +defined above.
 +
 +The ``name`` field is the name string of the statistics data. The name string
 +starts at the end of ``struct kvm_stats_desc``.  The maximum length including
 +the trailing ``'\0'``, is indicated by ``name_size`` in the header.
 +
 +The Stats Data block contains an array of 64-bit values in the same order
 +as the descriptors in Descriptors block.
 +
  5. The kvm_run structure
  ========================
  
@@@ -6584,45 -6397,32 +6620,69 @@@ system fingerprint.  To prevent userspa
  by running an enclave in a VM, KVM prevents access to privileged attributes by
  default.
  
 -See Documentation/x86/sgx/2.Kernel-internals.rst for more details.
 +See Documentation/x86/sgx.rst for more details.
 +
 +7.26 KVM_CAP_PPC_RPT_INVALIDATE
 +-------------------------------
 +
 +:Capability: KVM_CAP_PPC_RPT_INVALIDATE
 +:Architectures: ppc
 +:Type: vm
 +
 +This capability indicates that the kernel is capable of handling
 +H_RPT_INVALIDATE hcall.
 +
 +In order to enable the use of H_RPT_INVALIDATE in the guest,
 +user space might have to advertise it for the guest. For example,
 +IBM pSeries (sPAPR) guest starts using it if "hcall-rpt-invalidate" is
 +present in the "ibm,hypertas-functions" device-tree property.
 +
 +This capability is enabled for hypervisors on platforms like POWER9
 +that support radix MMU.
 +
 +7.27 KVM_CAP_EXIT_ON_EMULATION_FAILURE
 +--------------------------------------
 +
 +:Architectures: x86
 +:Parameters: args[0] whether the feature should be enabled or not
 +
 +When this capability is enabled, an emulation failure will result in an exit
 +to userspace with KVM_INTERNAL_ERROR (except when the emulator was invoked
 +to handle a VMware backdoor instruction). Furthermore, KVM will now provide up
 +to 15 instruction bytes for any exit to userspace resulting from an emulation
 +failure.  When these exits to userspace occur use the emulation_failure struct
 +instead of the internal struct.  They both have the same layout, but the
 +emulation_failure struct matches the content better.  It also explicitly
 +defines the 'flags' field which is used to describe the fields in the struct
 +that are valid (ie: if KVM_INTERNAL_ERROR_EMULATION_FLAG_INSTRUCTION_BYTES is
 +set in the 'flags' field then both 'insn_size' and 'insn_bytes' have valid data
 +in them.)
 +
  
+ 7.26 KVM_CAP_ARM_MTE
+ --------------------
+ 
+ :Architectures: arm64
+ :Parameters: none
+ 
+ This capability indicates that KVM (and the hardware) supports exposing the
+ Memory Tagging Extensions (MTE) to the guest. It must also be enabled by the
+ VMM before creating any VCPUs to allow the guest access. Note that MTE is only
+ available to a guest running in AArch64 mode and enabling this capability will
+ cause attempts to create AArch32 VCPUs to fail.
+ 
+ When enabled the guest is able to access tags associated with any memory given
+ to the guest. KVM will ensure that the tags are maintained during swap or
+ hibernation of the host; however the VMM needs to manually save/restore the
+ tags as appropriate if the VM is migrated.
+ 
+ When this capability is enabled all memory in memslots must be mapped as
+ not-shareable (no MAP_SHARED), attempts to create a memslot with a
+ MAP_SHARED mmap will result in an -EINVAL return.
+ 
+ When enabled the VMM may make use of the ``KVM_ARM_MTE_COPY_TAGS`` ioctl to
+ perform a bulk copy of tags to/from the guest.
+ 
  8. Other capabilities.
  ======================
  

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

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

[Stephen Rothwell]

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

Hi all,

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

  Documentation/virt/kvm/api.rst

between commit:

  6dba94035203 ("KVM: x86: Introduce KVM_GET_SREGS2 / KVM_SET_SREGS2")

from the kvm tree and commit:

  04c02c201d7e ("KVM: arm64: Document MTE capability and ioctl")

from the kvm-arm 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 Documentation/virt/kvm/api.rst
index ef81de1d4a9b,97661a97943f..000000000000
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@@ -5034,54 -5034,43 +5034,91 @@@ see KVM_XEN_VCPU_SET_ATTR above
  The KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADJUST type may not be used
  with the KVM_XEN_VCPU_GET_ATTR ioctl.
  
+ 4.130 KVM_ARM_MTE_COPY_TAGS
+ ---------------------------
+ 
+ :Capability: KVM_CAP_ARM_MTE
+ :Architectures: arm64
+ :Type: vm ioctl
+ :Parameters: struct kvm_arm_copy_mte_tags
+ :Returns: number of bytes copied, < 0 on error (-EINVAL for incorrect
+           arguments, -EFAULT if memory cannot be accessed).
+ 
+ ::
+ 
+   struct kvm_arm_copy_mte_tags {
+ 	__u64 guest_ipa;
+ 	__u64 length;
+ 	void __user *addr;
+ 	__u64 flags;
+ 	__u64 reserved[2];
+   };
+ 
+ Copies Memory Tagging Extension (MTE) tags to/from guest tag memory. The
+ ``guest_ipa`` and ``length`` fields must be ``PAGE_SIZE`` aligned. The ``addr``
+ field must point to a buffer which the tags will be copied to or from.
+ 
+ ``flags`` specifies the direction of copy, either ``KVM_ARM_TAGS_TO_GUEST`` or
+ ``KVM_ARM_TAGS_FROM_GUEST``.
+ 
+ The size of the buffer to store the tags is ``(length / 16)`` bytes
+ (granules in MTE are 16 bytes long). Each byte contains a single tag
+ value. This matches the format of ``PTRACE_PEEKMTETAGS`` and
+ ``PTRACE_POKEMTETAGS``.
+ 
+ If an error occurs before any data is copied then a negative error code is
+ returned. If some tags have been copied before an error occurs then the number
+ of bytes successfully copied is returned. If the call completes successfully
+ then ``length`` is returned.
+ 
 +
 +4.131 KVM_GET_SREGS2
 +------------------
 +
 +:Capability: KVM_CAP_SREGS2
 +:Architectures: x86
 +:Type: vcpu ioctl
 +:Parameters: struct kvm_sregs2 (out)
 +:Returns: 0 on success, -1 on error
 +
 +Reads special registers from the vcpu.
 +This ioctl (when supported) replaces the KVM_GET_SREGS.
 +
 +::
 +
 +struct kvm_sregs2 {
 +	/* out (KVM_GET_SREGS2) / in (KVM_SET_SREGS2) */
 +	struct kvm_segment cs, ds, es, fs, gs, ss;
 +	struct kvm_segment tr, ldt;
 +	struct kvm_dtable gdt, idt;
 +	__u64 cr0, cr2, cr3, cr4, cr8;
 +	__u64 efer;
 +	__u64 apic_base;
 +	__u64 flags;
 +	__u64 pdptrs[4];
 +};
 +
 +flags values for ``kvm_sregs2``:
 +
 +``KVM_SREGS2_FLAGS_PDPTRS_VALID``
 +
 +  Indicates thats the struct contain valid PDPTR values.
 +
 +
 +4.132 KVM_SET_SREGS2
 +------------------
 +
 +:Capability: KVM_CAP_SREGS2
 +:Architectures: x86
 +:Type: vcpu ioctl
 +:Parameters: struct kvm_sregs2 (in)
 +:Returns: 0 on success, -1 on error
 +
 +Writes special registers into the vcpu.
 +See KVM_GET_SREGS2 for the data structures.
 +This ioctl (when supported) replaces the KVM_SET_SREGS.
 +
 +
  5. The kvm_run structure
  ========================
  
@@@ -6408,26 -6397,32 +6445,50 @@@ system fingerprint.  To prevent userspa
  by running an enclave in a VM, KVM prevents access to privileged attributes by
  default.
  
 -See Documentation/x86/sgx/2.Kernel-internals.rst for more details.
 +See Documentation/x86/sgx.rst for more details.
 +
 +7.26 KVM_CAP_PPC_RPT_INVALIDATE
 +-------------------------------
 +
 +:Capability: KVM_CAP_PPC_RPT_INVALIDATE
 +:Architectures: ppc
 +:Type: vm
 +
 +This capability indicates that the kernel is capable of handling
 +H_RPT_INVALIDATE hcall.
 +
 +In order to enable the use of H_RPT_INVALIDATE in the guest,
 +user space might have to advertise it for the guest. For example,
 +IBM pSeries (sPAPR) guest starts using it if "hcall-rpt-invalidate" is
 +present in the "ibm,hypertas-functions" device-tree property.
 +
 +This capability is enabled for hypervisors on platforms like POWER9
 +that support radix MMU.
  
+ 7.26 KVM_CAP_ARM_MTE
+ --------------------
+ 
+ :Architectures: arm64
+ :Parameters: none
+ 
+ This capability indicates that KVM (and the hardware) supports exposing the
+ Memory Tagging Extensions (MTE) to the guest. It must also be enabled by the
+ VMM before creating any VCPUs to allow the guest access. Note that MTE is only
+ available to a guest running in AArch64 mode and enabling this capability will
+ cause attempts to create AArch32 VCPUs to fail.
+ 
+ When enabled the guest is able to access tags associated with any memory given
+ to the guest. KVM will ensure that the tags are maintained during swap or
+ hibernation of the host; however the VMM needs to manually save/restore the
+ tags as appropriate if the VM is migrated.
+ 
+ When this capability is enabled all memory in memslots must be mapped as
+ not-shareable (no MAP_SHARED), attempts to create a memslot with a
+ MAP_SHARED mmap will result in an -EINVAL return.
+ 
+ When enabled the VMM may make use of the ``KVM_ARM_MTE_COPY_TAGS`` ioctl to
+ perform a bulk copy of tags to/from the guest.
+ 
  8. Other capabilities.
  ======================
  

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

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

[Stephen Rothwell]

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

Hi all,

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

  tools/testing/selftests/kvm/Makefile

between commit:

  4c63c9234085 ("KVM: selftests: Hoist APIC functions out of individual tests")

from the kvm tree and commit:

  e3db7579ef35 ("KVM: selftests: Add exception handling support for aarch64")

from the kvm-arm 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 tools/testing/selftests/kvm/Makefile
index 61e2accd080d,36e4ebcc82f0..000000000000
--- a/tools/testing/selftests/kvm/Makefile
+++ b/tools/testing/selftests/kvm/Makefile
@@@ -34,8 -34,8 +34,8 @@@ ifeq ($(ARCH),s390
  endif
  
  LIBKVM = lib/assert.c lib/elf.c lib/io.c lib/kvm_util.c lib/rbtree.c lib/sparsebit.c lib/test_util.c lib/guest_modes.c lib/perf_test_util.c
 -LIBKVM_x86_64 = lib/x86_64/processor.c lib/x86_64/vmx.c lib/x86_64/svm.c lib/x86_64/ucall.c lib/x86_64/handlers.S
 +LIBKVM_x86_64 = lib/x86_64/apic.c lib/x86_64/processor.c lib/x86_64/vmx.c lib/x86_64/svm.c lib/x86_64/ucall.c lib/x86_64/handlers.S
- LIBKVM_aarch64 = lib/aarch64/processor.c lib/aarch64/ucall.c
+ LIBKVM_aarch64 = lib/aarch64/processor.c lib/aarch64/ucall.c lib/aarch64/handlers.S
  LIBKVM_s390x = lib/s390x/processor.c lib/s390x/ucall.c lib/s390x/diag318_test_handler.c
  
  TEST_GEN_PROGS_x86_64 = x86_64/cr4_cpuid_sync_test

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

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

[Stephen Rothwell]

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

Hi all,

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

  include/uapi/linux/kvm.h

between commits:

  8b13c36493d8 ("KVM: introduce KVM_CAP_SET_GUEST_DEBUG2")
  fe7e948837f3 ("KVM: x86: Add capability to grant VM access to privileged SGX attribute")
  54526d1fd593 ("KVM: x86: Support KVM VMs sharing SEV context")

from the kvm tree and commit:

  3bf725699bf6 ("KVM: arm64: Add support for the KVM PTP service")

from the kvm-arm 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 include/uapi/linux/kvm.h
index d76533498543,0e0f70c0d0dc..000000000000
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@@ -1078,9 -1078,7 +1078,10 @@@ struct kvm_ppc_resize_hpt 
  #define KVM_CAP_DIRTY_LOG_RING 192
  #define KVM_CAP_X86_BUS_LOCK_EXIT 193
  #define KVM_CAP_PPC_DAWR1 194
 -#define KVM_CAP_PTP_KVM 195
 +#define KVM_CAP_SET_GUEST_DEBUG2 195
 +#define KVM_CAP_SGX_ATTRIBUTE 196
 +#define KVM_CAP_VM_COPY_ENC_CONTEXT_FROM 197
++#define KVM_CAP_PTP_KVM 198
  
  #ifdef KVM_CAP_IRQ_ROUTING
  

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

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

[Stephen Rothwell]

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

Hi all,

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

  Documentation/virt/kvm/api.rst

between commit:

  24e7475f931a ("doc/virt/kvm: move KVM_CAP_PPC_MULTITCE in section 8")

from the kvm tree and commit:

  3bf725699bf6 ("KVM: arm64: Add support for the KVM PTP service")

from the kvm-arm 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 Documentation/virt/kvm/api.rst
index ee3446bf2a01,3f210953c135..000000000000
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@@ -6744,28 -6738,12 +6757,38 @@@ The KVM_XEN_HVM_CONFIG_RUNSTATE flag in
  features KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADDR/_CURRENT/_DATA/_ADJUST are
  supported by the KVM_XEN_VCPU_SET_ATTR/KVM_XEN_VCPU_GET_ATTR ioctls.
  
 -8.31 KVM_CAP_PTP_KVM
 +8.31 KVM_CAP_PPC_MULTITCE
 +-------------------------
 +
 +:Capability: KVM_CAP_PPC_MULTITCE
 +:Architectures: ppc
 +:Type: vm
 +
 +This capability means the kernel is capable of handling hypercalls
 +H_PUT_TCE_INDIRECT and H_STUFF_TCE without passing those into the user
 +space. This significantly accelerates DMA operations for PPC KVM guests.
 +User space should expect that its handlers for these hypercalls
 +are not going to be called if user space previously registered LIOBN
 +in KVM (via KVM_CREATE_SPAPR_TCE or similar calls).
 +
 +In order to enable H_PUT_TCE_INDIRECT and H_STUFF_TCE use in the guest,
 +user space might have to advertise it for the guest. For example,
 +IBM pSeries (sPAPR) guest starts using them if "hcall-multi-tce" is
 +present in the "ibm,hypertas-functions" device-tree property.
 +
 +The hypercalls mentioned above may or may not be processed successfully
 +in the kernel based fast path. If they can not be handled by the kernel,
 +they will get passed on to user space. So user space still has to have
 +an implementation for these despite the in kernel acceleration.
 +
 +This capability is always enabled.
++
++8.32 KVM_CAP_PTP_KVM
+ --------------------
+ 
+ :Architectures: arm64
+ 
+ This capability indicates that the KVM virtual PTP service is
+ supported in the host. A VMM can check whether the service is
+ available to the guest on migration.
+ 

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

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

[Stephen Rothwell]

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

Hi all,

On Mon, 13 Jul 2020 14:40:36 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the kvm-arm tree got a conflict in:
> 
>   arch/arm64/kvm/mmu.c
> 
> between commit:
> 
>   c1a33aebe91d ("KVM: arm64: Use common KVM implementation of MMU memory caches")
> 
> from the kvm tree and commit:
> 
>   a0e50aa3f4a8 ("KVM: arm64: Factor out stage 2 page table data from struct kvm")
> 
> from the kvm-arm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> diff --cc arch/arm64/kvm/mmu.c
> index 838aad520f1c,cd14c831d56f..000000000000
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@@ -124,11 -127,44 +127,12 @@@ static void stage2_dissolve_pud(struct 
>   	put_page(virt_to_page(pudp));
>   }
>   
> - static void clear_stage2_pgd_entry(struct kvm *kvm, pgd_t *pgd, phys_addr_t addr)
>  -static int mmu_topup_memory_cache(struct kvm_mmu_memory_cache *cache,
>  -				  int min, int max)
>  -{
>  -	void *page;
>  -
>  -	BUG_ON(max > KVM_NR_MEM_OBJS);
>  -	if (cache->nobjs >= min)
>  -		return 0;
>  -	while (cache->nobjs < max) {
>  -		page = (void *)__get_free_page(GFP_PGTABLE_USER);
>  -		if (!page)
>  -			return -ENOMEM;
>  -		cache->objects[cache->nobjs++] = page;
>  -	}
>  -	return 0;
>  -}
>  -
>  -static void mmu_free_memory_cache(struct kvm_mmu_memory_cache *mc)
>  -{
>  -	while (mc->nobjs)
>  -		free_page((unsigned long)mc->objects[--mc->nobjs]);
>  -}
>  -
>  -static void *mmu_memory_cache_alloc(struct kvm_mmu_memory_cache *mc)
>  -{
>  -	void *p;
>  -
>  -	BUG_ON(!mc || !mc->nobjs);
>  -	p = mc->objects[--mc->nobjs];
>  -	return p;
>  -}
>  -
> + static void clear_stage2_pgd_entry(struct kvm_s2_mmu *mmu, pgd_t *pgd, phys_addr_t addr)
>   {
> + 	struct kvm *kvm = mmu->kvm;
>   	p4d_t *p4d_table __maybe_unused = stage2_p4d_offset(kvm, pgd, 0UL);
>   	stage2_pgd_clear(kvm, pgd);
> - 	kvm_tlb_flush_vmid_ipa(kvm, addr);
> + 	kvm_tlb_flush_vmid_ipa(mmu, addr, S2_NO_LEVEL_HINT);
>   	stage2_p4d_free(kvm, p4d_table);
>   	put_page(virt_to_page(pgd));
>   }

This is now a conflict between the kvm-arm tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

On Mon, 13 Jul 2020 14:39:35 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the kvm-arm tree got conflicts in:
> 
>   arch/arm64/include/asm/kvm_coproc.h
>   arch/arm64/kvm/handle_exit.c
> 
> between commit:
> 
>   74cc7e0c35c1 ("KVM: arm64: clean up redundant 'kvm_run' parameters")
> 
> from the kvm tree and commits:
> 
>   6b33e0d64f85 ("KVM: arm64: Drop the target_table[] indirection")
>   750ed5669380 ("KVM: arm64: Remove the target table")
>   3a949f4c9354 ("KVM: arm64: Rename HSR to ESR")
> 
> from the kvm-arm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> diff --cc arch/arm64/include/asm/kvm_coproc.h
> index 454373704b8a,147f3a77e6a5..000000000000
> --- a/arch/arm64/include/asm/kvm_coproc.h
> +++ b/arch/arm64/include/asm/kvm_coproc.h
> @@@ -19,20 -19,12 +19,12 @@@ struct kvm_sys_reg_table 
>   	size_t num;
>   };
>   
> - struct kvm_sys_reg_target_table {
> - 	struct kvm_sys_reg_table table64;
> - 	struct kvm_sys_reg_table table32;
> - };
> - 
> - void kvm_register_target_sys_reg_table(unsigned int target,
> - 				       struct kvm_sys_reg_target_table *table);
> - 
>  -int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu, struct kvm_run *run);
>  -int kvm_handle_cp14_32(struct kvm_vcpu *vcpu, struct kvm_run *run);
>  -int kvm_handle_cp14_64(struct kvm_vcpu *vcpu, struct kvm_run *run);
>  -int kvm_handle_cp15_32(struct kvm_vcpu *vcpu, struct kvm_run *run);
>  -int kvm_handle_cp15_64(struct kvm_vcpu *vcpu, struct kvm_run *run);
>  -int kvm_handle_sys_reg(struct kvm_vcpu *vcpu, struct kvm_run *run);
>  +int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu);
>  +int kvm_handle_cp14_32(struct kvm_vcpu *vcpu);
>  +int kvm_handle_cp14_64(struct kvm_vcpu *vcpu);
>  +int kvm_handle_cp15_32(struct kvm_vcpu *vcpu);
>  +int kvm_handle_cp15_64(struct kvm_vcpu *vcpu);
>  +int kvm_handle_sys_reg(struct kvm_vcpu *vcpu);
>   
>   #define kvm_coproc_table_init kvm_sys_reg_table_init
>   void kvm_sys_reg_table_init(void);
> diff --cc arch/arm64/kvm/handle_exit.c
> index 1df3beafd73f,98ab33139982..000000000000
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@@ -87,9 -87,9 +87,9 @@@ static int handle_no_fpsimd(struct kvm_
>    * world-switches and schedule other host processes until there is an
>    * incoming IRQ or FIQ to the VM.
>    */
>  -static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  +static int kvm_handle_wfx(struct kvm_vcpu *vcpu)
>   {
> - 	if (kvm_vcpu_get_hsr(vcpu) & ESR_ELx_WFx_ISS_WFE) {
> + 	if (kvm_vcpu_get_esr(vcpu) & ESR_ELx_WFx_ISS_WFE) {
>   		trace_kvm_wfx_arm64(*vcpu_pc(vcpu), true);
>   		vcpu->stat.wfe_exit_stat++;
>   		kvm_vcpu_on_spin(vcpu, vcpu_mode_priv(vcpu));
> @@@ -114,12 -115,11 +114,12 @@@
>    * guest and host are using the same debug facilities it will be up to
>    * userspace to re-inject the correct exception for guest delivery.
>    *
>  - * @return: 0 (while setting run->exit_reason), -1 for error
>  + * @return: 0 (while setting vcpu->run->exit_reason), -1 for error
>    */
>  -static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  +static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu)
>   {
>  +	struct kvm_run *run = vcpu->run;
> - 	u32 hsr = kvm_vcpu_get_hsr(vcpu);
> + 	u32 esr = kvm_vcpu_get_esr(vcpu);
>   	int ret = 0;
>   
>   	run->exit_reason = KVM_EXIT_DEBUG;
> @@@ -144,12 -144,12 +144,12 @@@
>   	return ret;
>   }
>   
>  -static int kvm_handle_unknown_ec(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  +static int kvm_handle_unknown_ec(struct kvm_vcpu *vcpu)
>   {
> - 	u32 hsr = kvm_vcpu_get_hsr(vcpu);
> + 	u32 esr = kvm_vcpu_get_esr(vcpu);
>   
> - 	kvm_pr_unimpl("Unknown exception class: hsr: %#08x -- %s\n",
> - 		      hsr, esr_get_class_string(hsr));
> + 	kvm_pr_unimpl("Unknown exception class: esr: %#08x -- %s\n",
> + 		      esr, esr_get_class_string(esr));
>   
>   	kvm_inject_undefined(vcpu);
>   	return 1;
> @@@ -237,12 -237,11 +237,12 @@@ static int handle_trap_exceptions(struc
>    * Return > 0 to return to guest, < 0 on error, 0 (and set exit_reason) on
>    * proper exit to userspace.
>    */
>  -int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
>  -		       int exception_index)
>  +int handle_exit(struct kvm_vcpu *vcpu, int exception_index)
>   {
>  +	struct kvm_run *run = vcpu->run;
>  +
>   	if (ARM_SERROR_PENDING(exception_index)) {
> - 		u8 hsr_ec = ESR_ELx_EC(kvm_vcpu_get_hsr(vcpu));
> + 		u8 esr_ec = ESR_ELx_EC(kvm_vcpu_get_esr(vcpu));
>   
>   		/*
>   		 * HVC/SMC already have an adjusted PC, which we need

This is now a conflict between the kvm-arm tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/kvm/mmu.c

between commit:

  c1a33aebe91d ("KVM: arm64: Use common KVM implementation of MMU memory caches")

from the kvm tree and commit:

  a0e50aa3f4a8 ("KVM: arm64: Factor out stage 2 page table data from struct kvm")

from the kvm-arm 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/arm64/kvm/mmu.c
index 838aad520f1c,cd14c831d56f..000000000000
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@@ -124,11 -127,44 +127,12 @@@ static void stage2_dissolve_pud(struct 
  	put_page(virt_to_page(pudp));
  }
  
- static void clear_stage2_pgd_entry(struct kvm *kvm, pgd_t *pgd, phys_addr_t addr)
 -static int mmu_topup_memory_cache(struct kvm_mmu_memory_cache *cache,
 -				  int min, int max)
 -{
 -	void *page;
 -
 -	BUG_ON(max > KVM_NR_MEM_OBJS);
 -	if (cache->nobjs >= min)
 -		return 0;
 -	while (cache->nobjs < max) {
 -		page = (void *)__get_free_page(GFP_PGTABLE_USER);
 -		if (!page)
 -			return -ENOMEM;
 -		cache->objects[cache->nobjs++] = page;
 -	}
 -	return 0;
 -}
 -
 -static void mmu_free_memory_cache(struct kvm_mmu_memory_cache *mc)
 -{
 -	while (mc->nobjs)
 -		free_page((unsigned long)mc->objects[--mc->nobjs]);
 -}
 -
 -static void *mmu_memory_cache_alloc(struct kvm_mmu_memory_cache *mc)
 -{
 -	void *p;
 -
 -	BUG_ON(!mc || !mc->nobjs);
 -	p = mc->objects[--mc->nobjs];
 -	return p;
 -}
 -
+ static void clear_stage2_pgd_entry(struct kvm_s2_mmu *mmu, pgd_t *pgd, phys_addr_t addr)
  {
+ 	struct kvm *kvm = mmu->kvm;
  	p4d_t *p4d_table __maybe_unused = stage2_p4d_offset(kvm, pgd, 0UL);
  	stage2_pgd_clear(kvm, pgd);
- 	kvm_tlb_flush_vmid_ipa(kvm, addr);
+ 	kvm_tlb_flush_vmid_ipa(mmu, addr, S2_NO_LEVEL_HINT);
  	stage2_p4d_free(kvm, p4d_table);
  	put_page(virt_to_page(pgd));
  }

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

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the kvm-arm tree got conflicts in:

  arch/arm64/include/asm/kvm_coproc.h
  arch/arm64/kvm/handle_exit.c

between commit:

  74cc7e0c35c1 ("KVM: arm64: clean up redundant 'kvm_run' parameters")

from the kvm tree and commits:

  6b33e0d64f85 ("KVM: arm64: Drop the target_table[] indirection")
  750ed5669380 ("KVM: arm64: Remove the target table")
  3a949f4c9354 ("KVM: arm64: Rename HSR to ESR")

from the kvm-arm 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/arm64/include/asm/kvm_coproc.h
index 454373704b8a,147f3a77e6a5..000000000000
--- a/arch/arm64/include/asm/kvm_coproc.h
+++ b/arch/arm64/include/asm/kvm_coproc.h
@@@ -19,20 -19,12 +19,12 @@@ struct kvm_sys_reg_table 
  	size_t num;
  };
  
- struct kvm_sys_reg_target_table {
- 	struct kvm_sys_reg_table table64;
- 	struct kvm_sys_reg_table table32;
- };
- 
- void kvm_register_target_sys_reg_table(unsigned int target,
- 				       struct kvm_sys_reg_target_table *table);
- 
 -int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu, struct kvm_run *run);
 -int kvm_handle_cp14_32(struct kvm_vcpu *vcpu, struct kvm_run *run);
 -int kvm_handle_cp14_64(struct kvm_vcpu *vcpu, struct kvm_run *run);
 -int kvm_handle_cp15_32(struct kvm_vcpu *vcpu, struct kvm_run *run);
 -int kvm_handle_cp15_64(struct kvm_vcpu *vcpu, struct kvm_run *run);
 -int kvm_handle_sys_reg(struct kvm_vcpu *vcpu, struct kvm_run *run);
 +int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu);
 +int kvm_handle_cp14_32(struct kvm_vcpu *vcpu);
 +int kvm_handle_cp14_64(struct kvm_vcpu *vcpu);
 +int kvm_handle_cp15_32(struct kvm_vcpu *vcpu);
 +int kvm_handle_cp15_64(struct kvm_vcpu *vcpu);
 +int kvm_handle_sys_reg(struct kvm_vcpu *vcpu);
  
  #define kvm_coproc_table_init kvm_sys_reg_table_init
  void kvm_sys_reg_table_init(void);
diff --cc arch/arm64/kvm/handle_exit.c
index 1df3beafd73f,98ab33139982..000000000000
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@@ -87,9 -87,9 +87,9 @@@ static int handle_no_fpsimd(struct kvm_
   * world-switches and schedule other host processes until there is an
   * incoming IRQ or FIQ to the VM.
   */
 -static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct kvm_run *run)
 +static int kvm_handle_wfx(struct kvm_vcpu *vcpu)
  {
- 	if (kvm_vcpu_get_hsr(vcpu) & ESR_ELx_WFx_ISS_WFE) {
+ 	if (kvm_vcpu_get_esr(vcpu) & ESR_ELx_WFx_ISS_WFE) {
  		trace_kvm_wfx_arm64(*vcpu_pc(vcpu), true);
  		vcpu->stat.wfe_exit_stat++;
  		kvm_vcpu_on_spin(vcpu, vcpu_mode_priv(vcpu));
@@@ -114,12 -115,11 +114,12 @@@
   * guest and host are using the same debug facilities it will be up to
   * userspace to re-inject the correct exception for guest delivery.
   *
 - * @return: 0 (while setting run->exit_reason), -1 for error
 + * @return: 0 (while setting vcpu->run->exit_reason), -1 for error
   */
 -static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, struct kvm_run *run)
 +static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu)
  {
 +	struct kvm_run *run = vcpu->run;
- 	u32 hsr = kvm_vcpu_get_hsr(vcpu);
+ 	u32 esr = kvm_vcpu_get_esr(vcpu);
  	int ret = 0;
  
  	run->exit_reason = KVM_EXIT_DEBUG;
@@@ -144,12 -144,12 +144,12 @@@
  	return ret;
  }
  
 -static int kvm_handle_unknown_ec(struct kvm_vcpu *vcpu, struct kvm_run *run)
 +static int kvm_handle_unknown_ec(struct kvm_vcpu *vcpu)
  {
- 	u32 hsr = kvm_vcpu_get_hsr(vcpu);
+ 	u32 esr = kvm_vcpu_get_esr(vcpu);
  
- 	kvm_pr_unimpl("Unknown exception class: hsr: %#08x -- %s\n",
- 		      hsr, esr_get_class_string(hsr));
+ 	kvm_pr_unimpl("Unknown exception class: esr: %#08x -- %s\n",
+ 		      esr, esr_get_class_string(esr));
  
  	kvm_inject_undefined(vcpu);
  	return 1;
@@@ -237,12 -237,11 +237,12 @@@ static int handle_trap_exceptions(struc
   * Return > 0 to return to guest, < 0 on error, 0 (and set exit_reason) on
   * proper exit to userspace.
   */
 -int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
 -		       int exception_index)
 +int handle_exit(struct kvm_vcpu *vcpu, int exception_index)
  {
 +	struct kvm_run *run = vcpu->run;
 +
  	if (ARM_SERROR_PENDING(exception_index)) {
- 		u8 hsr_ec = ESR_ELx_EC(kvm_vcpu_get_hsr(vcpu));
+ 		u8 esr_ec = ESR_ELx_EC(kvm_vcpu_get_esr(vcpu));
  
  		/*
  		 * HVC/SMC already have an adjusted PC, which we need

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

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm/kvm/coproc.c

between commit:

  4d395762599d ("KVM: Remove unnecessary asm/kvm_host.h includes")

from the kvm tree and commit:

  541ad0150ca4 ("arm: Remove 32bit KVM host support")

from the kvm-arm tree.

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

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

  include/uapi/linux/kvm.h

between commits:

  214ff83d4473 ("KVM: x86: hyperv: implement PV IPI send hypercalls")
  0804c849f1df ("kvm/x86 : add coalesced pio support")
  57b119da3594 ("KVM: nVMX: add KVM_CAP_HYPERV_ENLIGHTENED_VMCS capability")
  c4f55198c7c2 ("kvm: x86: Introduce KVM_CAP_EXCEPTION_PAYLOAD")

from the kvm tree and commit:

  233a7cb23531 ("kvm: arm64: Allow tuning the physical address size for VM")

from the kvm-arm 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 include/uapi/linux/kvm.h
index cb6d44e1fe02,95aa73ca65dc..000000000000
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@@ -960,11 -962,7 +969,12 @@@ struct kvm_ppc_resize_hpt 
  #define KVM_CAP_NESTED_STATE 157
  #define KVM_CAP_ARM_INJECT_SERROR_ESR 158
  #define KVM_CAP_MSR_PLATFORM_INFO 159
 -#define KVM_CAP_ARM_VM_IPA_SIZE 160 /* returns maximum IPA bits for a VM */
 +#define KVM_CAP_PPC_NESTED_HV 160
 +#define KVM_CAP_HYPERV_SEND_IPI 161
 +#define KVM_CAP_COALESCED_PIO 162
 +#define KVM_CAP_HYPERV_ENLIGHTENED_VMCS 163
 +#define KVM_CAP_EXCEPTION_PAYLOAD 164
++#define KVM_CAP_ARM_VM_IPA_SIZE 165 /* returns maximum IPA bits for a VM */
  
  #ifdef KVM_CAP_IRQ_ROUTING
  

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

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

[Christoffer Dall]

Hi Stephen,

On Mon, Apr 10, 2017 at 01:52:42PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm-arm tree got conflicts in:
> 
>   Documentation/virtual/kvm/api.txt
>   include/uapi/linux/kvm.h
> 
> between commits:
> 
>   a8a3c426772e ("KVM: MIPS: Add VZ & TE capabilities")
>   578fd61d2d21 ("KVM: MIPS: Add 64BIT capability")
> 
> from the kvm tree and commit:
> 
>   3fe17e682616 ("KVM: arm/arm64: Add ARM user space interrupt signaling ABI")
> 
> from the kvm-arm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

The resolution looks good to me.

Thanks,
-Christoffer

> 
> diff --cc Documentation/virtual/kvm/api.txt
> index 1a184843bf9c,3b4e76e5201e..000000000000
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@@ -4030,67 -4148,44 +4030,108 @@@ available, means that that the kernel c
>   hashed page table MMU defined in Power ISA V3.00 (as implemented in
>   the POWER9 processor), including in-memory segment tables.
>   
>  +8.5 KVM_CAP_MIPS_VZ
>  +
>  +Architectures: mips
>  +
>  +This capability, if KVM_CHECK_EXTENSION on the main kvm handle indicates that
>  +it is available, means that full hardware assisted virtualization capabilities
>  +of the hardware are available for use through KVM. An appropriate
>  +KVM_VM_MIPS_* type must be passed to KVM_CREATE_VM to create a VM which
>  +utilises it.
>  +
>  +If KVM_CHECK_EXTENSION on a kvm VM handle indicates that this capability is
>  +available, it means that the VM is using full hardware assisted virtualization
>  +capabilities of the hardware. This is useful to check after creating a VM with
>  +KVM_VM_MIPS_DEFAULT.
>  +
>  +The value returned by KVM_CHECK_EXTENSION should be compared against known
>  +values (see below). All other values are reserved. This is to allow for the
>  +possibility of other hardware assisted virtualization implementations which
>  +may be incompatible with the MIPS VZ ASE.
>  +
>  + 0: The trap & emulate implementation is in use to run guest code in user
>  +    mode. Guest virtual memory segments are rearranged to fit the guest in the
>  +    user mode address space.
>  +
>  + 1: The MIPS VZ ASE is in use, providing full hardware assisted
>  +    virtualization, including standard guest virtual memory segments.
>  +
>  +8.6 KVM_CAP_MIPS_TE
>  +
>  +Architectures: mips
>  +
>  +This capability, if KVM_CHECK_EXTENSION on the main kvm handle indicates that
>  +it is available, means that the trap & emulate implementation is available to
>  +run guest code in user mode, even if KVM_CAP_MIPS_VZ indicates that hardware
>  +assisted virtualisation is also available. KVM_VM_MIPS_TE (0) must be passed
>  +to KVM_CREATE_VM to create a VM which utilises it.
>  +
>  +If KVM_CHECK_EXTENSION on a kvm VM handle indicates that this capability is
>  +available, it means that the VM is using trap & emulate.
>  +
>  +8.7 KVM_CAP_MIPS_64BIT
>  +
>  +Architectures: mips
>  +
>  +This capability indicates the supported architecture type of the guest, i.e. the
>  +supported register and address width.
>  +
>  +The values returned when this capability is checked by KVM_CHECK_EXTENSION on a
>  +kvm VM handle correspond roughly to the CP0_Config.AT register field, and should
>  +be checked specifically against known values (see below). All other values are
>  +reserved.
>  +
>  + 0: MIPS32 or microMIPS32.
>  +    Both registers and addresses are 32-bits wide.
>  +    It will only be possible to run 32-bit guest code.
>  +
>  + 1: MIPS64 or microMIPS64 with access only to 32-bit compatibility segments.
>  +    Registers are 64-bits wide, but addresses are 32-bits wide.
>  +    64-bit guest code may run but cannot access MIPS64 memory segments.
>  +    It will also be possible to run 32-bit guest code.
>  +
>  + 2: MIPS64 or microMIPS64 with access to all address segments.
>  +    Both registers and addresses are 64-bits wide.
>  +    It will be possible to run 64-bit or 32-bit guest code.
> + 
>  -8.5 KVM_CAP_ARM_USER_IRQ
> ++8.8 KVM_CAP_ARM_USER_IRQ
> + 
> + Architectures: arm, arm64
> + This capability, if KVM_CHECK_EXTENSION indicates that it is available, means
> + that if userspace creates a VM without an in-kernel interrupt controller, it
> + will be notified of changes to the output level of in-kernel emulated devices,
> + which can generate virtual interrupts, presented to the VM.
> + For such VMs, on every return to userspace, the kernel
> + updates the vcpu's run->s.regs.device_irq_level field to represent the actual
> + output level of the device.
> + 
> + Whenever kvm detects a change in the device output level, kvm guarantees at
> + least one return to userspace before running the VM.  This exit could either
> + be a KVM_EXIT_INTR or any other exit event, like KVM_EXIT_MMIO. This way,
> + userspace can always sample the device output level and re-compute the state of
> + the userspace interrupt controller.  Userspace should always check the state
> + of run->s.regs.device_irq_level on every kvm exit.
> + The value in run->s.regs.device_irq_level can represent both level and edge
> + triggered interrupt signals, depending on the device.  Edge triggered interrupt
> + signals will exit to userspace with the bit in run->s.regs.device_irq_level
> + set exactly once per edge signal.
> + 
> + The field run->s.regs.device_irq_level is available independent of
> + run->kvm_valid_regs or run->kvm_dirty_regs bits.
> + 
> + If KVM_CAP_ARM_USER_IRQ is supported, the KVM_CHECK_EXTENSION ioctl returns a
> + number larger than 0 indicating the version of this capability is implemented
> + and thereby which bits in in run->s.regs.device_irq_level can signal values.
> + 
> + Currently the following bits are defined for the device_irq_level bitmap:
> + 
> +   KVM_CAP_ARM_USER_IRQ >= 1:
> + 
> +     KVM_ARM_DEV_EL1_VTIMER -  EL1 virtual timer
> +     KVM_ARM_DEV_EL1_PTIMER -  EL1 physical timer
> +     KVM_ARM_DEV_PMU        -  ARM PMU overflow interrupt signal
> + 
> + Future versions of kvm may implement additional events. These will get
> + indicated by returning a higher number from KVM_CHECK_EXTENSION and will be
> + listed above.
> diff --cc include/uapi/linux/kvm.h
> index 1e1a6c728a18,6d6b9b237f0b..000000000000
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@@ -887,9 -883,7 +887,10 @@@ struct kvm_ppc_resize_hpt 
>   #define KVM_CAP_PPC_MMU_RADIX 134
>   #define KVM_CAP_PPC_MMU_HASH_V3 135
>   #define KVM_CAP_IMMEDIATE_EXIT 136
>  -#define KVM_CAP_ARM_USER_IRQ 137
>  +#define KVM_CAP_MIPS_VZ 137
>  +#define KVM_CAP_MIPS_TE 138
>  +#define KVM_CAP_MIPS_64BIT 139
> ++#define KVM_CAP_ARM_USER_IRQ 140
>   
>   #ifdef KVM_CAP_IRQ_ROUTING
>   

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm-arm tree got conflicts in:

  Documentation/virtual/kvm/api.txt
  include/uapi/linux/kvm.h

between commits:

  a8a3c426772e ("KVM: MIPS: Add VZ & TE capabilities")
  578fd61d2d21 ("KVM: MIPS: Add 64BIT capability")

from the kvm tree and commit:

  3fe17e682616 ("KVM: arm/arm64: Add ARM user space interrupt signaling ABI")

from the kvm-arm 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 Documentation/virtual/kvm/api.txt
index 1a184843bf9c,3b4e76e5201e..000000000000
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@@ -4030,67 -4148,44 +4030,108 @@@ available, means that that the kernel c
  hashed page table MMU defined in Power ISA V3.00 (as implemented in
  the POWER9 processor), including in-memory segment tables.
  
 +8.5 KVM_CAP_MIPS_VZ
 +
 +Architectures: mips
 +
 +This capability, if KVM_CHECK_EXTENSION on the main kvm handle indicates that
 +it is available, means that full hardware assisted virtualization capabilities
 +of the hardware are available for use through KVM. An appropriate
 +KVM_VM_MIPS_* type must be passed to KVM_CREATE_VM to create a VM which
 +utilises it.
 +
 +If KVM_CHECK_EXTENSION on a kvm VM handle indicates that this capability is
 +available, it means that the VM is using full hardware assisted virtualization
 +capabilities of the hardware. This is useful to check after creating a VM with
 +KVM_VM_MIPS_DEFAULT.
 +
 +The value returned by KVM_CHECK_EXTENSION should be compared against known
 +values (see below). All other values are reserved. This is to allow for the
 +possibility of other hardware assisted virtualization implementations which
 +may be incompatible with the MIPS VZ ASE.
 +
 + 0: The trap & emulate implementation is in use to run guest code in user
 +    mode. Guest virtual memory segments are rearranged to fit the guest in the
 +    user mode address space.
 +
 + 1: The MIPS VZ ASE is in use, providing full hardware assisted
 +    virtualization, including standard guest virtual memory segments.
 +
 +8.6 KVM_CAP_MIPS_TE
 +
 +Architectures: mips
 +
 +This capability, if KVM_CHECK_EXTENSION on the main kvm handle indicates that
 +it is available, means that the trap & emulate implementation is available to
 +run guest code in user mode, even if KVM_CAP_MIPS_VZ indicates that hardware
 +assisted virtualisation is also available. KVM_VM_MIPS_TE (0) must be passed
 +to KVM_CREATE_VM to create a VM which utilises it.
 +
 +If KVM_CHECK_EXTENSION on a kvm VM handle indicates that this capability is
 +available, it means that the VM is using trap & emulate.
 +
 +8.7 KVM_CAP_MIPS_64BIT
 +
 +Architectures: mips
 +
 +This capability indicates the supported architecture type of the guest, i.e. the
 +supported register and address width.
 +
 +The values returned when this capability is checked by KVM_CHECK_EXTENSION on a
 +kvm VM handle correspond roughly to the CP0_Config.AT register field, and should
 +be checked specifically against known values (see below). All other values are
 +reserved.
 +
 + 0: MIPS32 or microMIPS32.
 +    Both registers and addresses are 32-bits wide.
 +    It will only be possible to run 32-bit guest code.
 +
 + 1: MIPS64 or microMIPS64 with access only to 32-bit compatibility segments.
 +    Registers are 64-bits wide, but addresses are 32-bits wide.
 +    64-bit guest code may run but cannot access MIPS64 memory segments.
 +    It will also be possible to run 32-bit guest code.
 +
 + 2: MIPS64 or microMIPS64 with access to all address segments.
 +    Both registers and addresses are 64-bits wide.
 +    It will be possible to run 64-bit or 32-bit guest code.
+ 
 -8.5 KVM_CAP_ARM_USER_IRQ
++8.8 KVM_CAP_ARM_USER_IRQ
+ 
+ Architectures: arm, arm64
+ This capability, if KVM_CHECK_EXTENSION indicates that it is available, means
+ that if userspace creates a VM without an in-kernel interrupt controller, it
+ will be notified of changes to the output level of in-kernel emulated devices,
+ which can generate virtual interrupts, presented to the VM.
+ For such VMs, on every return to userspace, the kernel
+ updates the vcpu's run->s.regs.device_irq_level field to represent the actual
+ output level of the device.
+ 
+ Whenever kvm detects a change in the device output level, kvm guarantees at
+ least one return to userspace before running the VM.  This exit could either
+ be a KVM_EXIT_INTR or any other exit event, like KVM_EXIT_MMIO. This way,
+ userspace can always sample the device output level and re-compute the state of
+ the userspace interrupt controller.  Userspace should always check the state
+ of run->s.regs.device_irq_level on every kvm exit.
+ The value in run->s.regs.device_irq_level can represent both level and edge
+ triggered interrupt signals, depending on the device.  Edge triggered interrupt
+ signals will exit to userspace with the bit in run->s.regs.device_irq_level
+ set exactly once per edge signal.
+ 
+ The field run->s.regs.device_irq_level is available independent of
+ run->kvm_valid_regs or run->kvm_dirty_regs bits.
+ 
+ If KVM_CAP_ARM_USER_IRQ is supported, the KVM_CHECK_EXTENSION ioctl returns a
+ number larger than 0 indicating the version of this capability is implemented
+ and thereby which bits in in run->s.regs.device_irq_level can signal values.
+ 
+ Currently the following bits are defined for the device_irq_level bitmap:
+ 
+   KVM_CAP_ARM_USER_IRQ >= 1:
+ 
+     KVM_ARM_DEV_EL1_VTIMER -  EL1 virtual timer
+     KVM_ARM_DEV_EL1_PTIMER -  EL1 physical timer
+     KVM_ARM_DEV_PMU        -  ARM PMU overflow interrupt signal
+ 
+ Future versions of kvm may implement additional events. These will get
+ indicated by returning a higher number from KVM_CHECK_EXTENSION and will be
+ listed above.
diff --cc include/uapi/linux/kvm.h
index 1e1a6c728a18,6d6b9b237f0b..000000000000
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@@ -887,9 -883,7 +887,10 @@@ struct kvm_ppc_resize_hpt 
  #define KVM_CAP_PPC_MMU_RADIX 134
  #define KVM_CAP_PPC_MMU_HASH_V3 135
  #define KVM_CAP_IMMEDIATE_EXIT 136
 -#define KVM_CAP_ARM_USER_IRQ 137
 +#define KVM_CAP_MIPS_VZ 137
 +#define KVM_CAP_MIPS_TE 138
 +#define KVM_CAP_MIPS_64BIT 139
++#define KVM_CAP_ARM_USER_IRQ 140
  
  #ifdef KVM_CAP_IRQ_ROUTING
  

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

[Stephen Rothwell]

Hi all,

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

  virt/kvm/irqchip.c

between commit:

  c63cf538eb4b ("KVM: pass struct kvm to kvm_set_routing_entry")

from the kvm tree and commit:

  995a0ee9809b ("KVM: arm/arm64: Enable MSI routing")

from the kvm-arm 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 virt/kvm/irqchip.c
index df99e9c3b64d,c6202199e505..000000000000
--- a/virt/kvm/irqchip.c
+++ b/virt/kvm/irqchip.c
@@@ -208,15 -208,19 +209,19 @@@ int kvm_set_irq_routing(struct kvm *kvm
  			goto out;
  
  		r = -EINVAL;
- 		if (ue->flags) {
- 			kfree(e);
- 			goto out;
+ 		switch (ue->type) {
+ 		case KVM_IRQ_ROUTING_MSI:
+ 			if (ue->flags & ~KVM_MSI_VALID_DEVID)
+ 				goto free_entry;
+ 			break;
+ 		default:
+ 			if (ue->flags)
+ 				goto free_entry;
+ 			break;
  		}
 -		r = setup_routing_entry(new, e, ue);
 +		r = setup_routing_entry(kvm, new, e, ue);
- 		if (r) {
- 			kfree(e);
- 			goto out;
- 		}
+ 		if (r)
+ 			goto free_entry;
  		++ue;
  	}
  

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

[Stephen Rothwell]

Hi all,

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

  Documentation/virtual/kvm/api.txt

between commit:

  3713131345fb ("KVM: x86: add KVM_CAP_X2APIC_API")

from the kvm tree and commit:

  76a10b86785c ("KVM: api: Pass the devid in the msi routing entry")

from the kvm-arm 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 Documentation/virtual/kvm/api.txt
index 5237e1b2fd66,7a04216d7278..000000000000
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@@ -1479,14 -1486,20 +1486,25 @@@ struct kvm_irq_routing_msi 
  	__u32 address_lo;
  	__u32 address_hi;
  	__u32 data;
- 	__u32 pad;
+ 	union {
+ 		__u32 pad;
+ 		__u32 devid;
+ 	};
  };
  
 +On x86, address_hi is ignored unless the KVM_X2APIC_API_USE_32BIT_IDS
 +feature of KVM_CAP_X2APIC_API capability is enabled.  If it is enabled,
 +address_hi bits 31-8 provide bits 31-8 of the destination id.  Bits 7-0 of
 +address_hi must be zero.
 +
+ devid: If KVM_MSI_VALID_DEVID is set, contains a unique device identifier
+        for the device that wrote the MSI message.
+        For PCI, this is usually a BFD identifier in the lower 16 bits.
+ 
+ The per-VM KVM_CAP_MSI_DEVID capability advertises the requirement to
+ provide the device ID. If this capability is not set, userland cannot
+ rely on the kernel to allow the KVM_MSI_VALID_DEVID flag being set.
+ 
  struct kvm_irq_routing_s390_adapter {
  	__u64 ind_addr;
  	__u64 summary_addr;

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

[Stephen Rothwell]

Hi all,

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

  include/uapi/linux/kvm.h

between commit:

  3713131345fb ("KVM: x86: add KVM_CAP_X2APIC_API")

from the kvm tree and commit:

  2b8ddd9337ee ("KVM: Extend struct kvm_msi to hold a 32-bit device ID")

from the kvm-arm 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 include/uapi/linux/kvm.h
index 4f8030e5b05d,d8c4c324cfae..000000000000
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@@ -866,7 -866,7 +866,8 @@@ struct kvm_ppc_smmu_info 
  #define KVM_CAP_ARM_PMU_V3 126
  #define KVM_CAP_VCPU_ATTRIBUTES 127
  #define KVM_CAP_MAX_VCPU_ID 128
 -#define KVM_CAP_MSI_DEVID 129
 +#define KVM_CAP_X2APIC_API 129
++#define KVM_CAP_MSI_DEVID 130
  
  #ifdef KVM_CAP_IRQ_ROUTING
  

RE: linux-next: manual merge of the kvm-arm tree with the kvm tree

[Wu, Feng]

> -----Original Message-----
> From: Stephen Rothwell [mailto:sfr@canb.auug.org.au]
> Sent: Friday, October 16, 2015 11:53 AM
> To: Christoffer Dall <cdall@cs.columbia.edu>; Marc Zyngier
> <marc.zyngier@arm.com>; Marcelo Tosatti <mtosatti@redhat.com>; Gleb
> Natapov <gleb@kernel.org>; kvm@vger.kernel.org
> Cc: linux-next@vger.kernel.org; linux-kernel@vger.kernel.org; Wu, Feng
> <feng.wu@intel.com>; Paolo Bonzini <pbonzini@redhat.com>; Christian
> Borntraeger <borntraeger@de.ibm.com>; Cornelia Huck
> <cornelia.huck@de.ibm.com>
> Subject: linux-next: manual merge of the kvm-arm tree with the kvm tree
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Thanks Stephen!

Thanks,
Feng

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

[Stephen Rothwell]

Hi all,

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

  arch/x86/include/asm/kvm_host.h

between commit:

  d84f1e0755ba ("KVM: make kvm_set_msi_irq() public")

from the kvm tree and commits:

  8feb4a04dc75 ("KVM: Define a new interface kvm_intr_is_single_vcpu()")
  8fc52eb9cee4 ("KVM: Add kvm_arch_vcpu_{un}blocking callbacks")

from the kvm-arm 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 arch/x86/include/asm/kvm_host.h
index 53deb2750bf6,b926137d591f..000000000000
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@@ -1256,9 -1232,7 +1256,13 @@@ int x86_set_memory_region(struct kvm *k
  bool kvm_vcpu_is_reset_bsp(struct kvm_vcpu *vcpu);
  bool kvm_vcpu_is_bsp(struct kvm_vcpu *vcpu);
  
 +bool kvm_intr_is_single_vcpu(struct kvm *kvm, struct kvm_lapic_irq *irq,
 +			     struct kvm_vcpu **dest_vcpu);
 +
 +void kvm_set_msi_irq(struct kvm_kernel_irq_routing_entry *e,
 +		     struct kvm_lapic_irq *irq);
++
+ static inline void kvm_arch_vcpu_blocking(struct kvm_vcpu *vcpu) {}
+ static inline void kvm_arch_vcpu_unblocking(struct kvm_vcpu *vcpu) {}
+ 
  #endif /* _ASM_X86_KVM_HOST_H */

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

[Christoffer Dall]

Thanks Stephen, it was (obviously) the right fix.

-Christoffer

On Wed, Nov 26, 2014 at 7:19 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the kvm-arm tree got a conflict in
> arch/ia64/kvm/kvm-ia64.c between commit 003f7de62589 ("KVM: ia64:
> remove") from the kvm tree and commit bf4bea8e9a90 ("kvm: fix
> kvm_is_mmio_pfn() and rename to kvm_is_reserved_pfn()") from the
> kvm-arm tree.
>
> I fixed it up (the former removed the file, so I did that) and can
> carry the fix as necessary (no action is required).
>
> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in
arch/ia64/kvm/kvm-ia64.c between commit 003f7de62589 ("KVM: ia64:
remove") from the kvm tree and commit bf4bea8e9a90 ("kvm: fix
kvm_is_mmio_pfn() and rename to kvm_is_reserved_pfn()") from the
kvm-arm tree.

I fixed it up (the former removed the file, so I did that) and can
carry the fix as necessary (no action is required).

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

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

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in
virt/kvm/eventfd.c between commit 29f1b65b5984 ("KVM: EVENTFD: Remove
inclusion of irq.h") from the kvm tree and commit 0ba09511ddc3 ("KVM:
EVENTFD: remove inclusion of irq.h") from the kvm-arm tree.

I fixed it up (I used the kvm tree version) and can carry the fix as
necessary (no action is required).
git diff
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

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

[Marc Zyngier]

On Thu, Sep 18 2014 at 04:52:26 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the kvm-arm tree got a conflict in
> virt/kvm/arm/vgic.c between commit c06a841bf363 ("KVM: ARM: vgic:
> register kvm_device_ops dynamically") from the kvm tree and commit
> de56fb1923ca ("KVM: vgic: declare probe function pointer as const")
> from the kvm-arm tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Looks good, thanks Stephen.

	M.
-- 
Jazz is not dead. It just smells funny.

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in
virt/kvm/arm/vgic.c between commit c06a841bf363 ("KVM: ARM: vgic:
register kvm_device_ops dynamically") from the kvm tree and commit
de56fb1923ca ("KVM: vgic: declare probe function pointer as const")
from the kvm-arm 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 virt/kvm/arm/vgic.c
index 3ee3ce06bbec,efe6eee2e7eb..000000000000
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@@ -1993,81 -2070,3 +1993,81 @@@ static struct kvm_device_ops kvm_arm_vg
  	.get_attr = vgic_get_attr,
  	.has_attr = vgic_has_attr,
  };
 +
 +static void vgic_init_maintenance_interrupt(void *info)
 +{
 +	enable_percpu_irq(vgic->maint_irq, 0);
 +}
 +
 +static int vgic_cpu_notify(struct notifier_block *self,
 +			   unsigned long action, void *cpu)
 +{
 +	switch (action) {
 +	case CPU_STARTING:
 +	case CPU_STARTING_FROZEN:
 +		vgic_init_maintenance_interrupt(NULL);
 +		break;
 +	case CPU_DYING:
 +	case CPU_DYING_FROZEN:
 +		disable_percpu_irq(vgic->maint_irq);
 +		break;
 +	}
 +
 +	return NOTIFY_OK;
 +}
 +
 +static struct notifier_block vgic_cpu_nb = {
 +	.notifier_call = vgic_cpu_notify,
 +};
 +
 +static const struct of_device_id vgic_ids[] = {
 +	{ .compatible = "arm,cortex-a15-gic", .data = vgic_v2_probe, },
 +	{ .compatible = "arm,gic-v3", .data = vgic_v3_probe, },
 +	{},
 +};
 +
 +int kvm_vgic_hyp_init(void)
 +{
 +	const struct of_device_id *matched_id;
- 	int (*vgic_probe)(struct device_node *,const struct vgic_ops **,
++	const int (*vgic_probe)(struct device_node *,const struct vgic_ops **,
 +			  const struct vgic_params **);
 +	struct device_node *vgic_node;
 +	int ret;
 +
 +	vgic_node = of_find_matching_node_and_match(NULL,
 +						    vgic_ids, &matched_id);
 +	if (!vgic_node) {
 +		kvm_err("error: no compatible GIC node found\n");
 +		return -ENODEV;
 +	}
 +
 +	vgic_probe = matched_id->data;
 +	ret = vgic_probe(vgic_node, &vgic_ops, &vgic);
 +	if (ret)
 +		return ret;
 +
 +	ret = request_percpu_irq(vgic->maint_irq, vgic_maintenance_handler,
 +				 "vgic", kvm_get_running_vcpus());
 +	if (ret) {
 +		kvm_err("Cannot register interrupt %d\n", vgic->maint_irq);
 +		return ret;
 +	}
 +
 +	ret = __register_cpu_notifier(&vgic_cpu_nb);
 +	if (ret) {
 +		kvm_err("Cannot register vgic CPU notifier\n");
 +		goto out_free_irq;
 +	}
 +
 +	/* Callback into for arch code for setup */
 +	vgic_arch_setup(vgic);
 +
 +	on_each_cpu(vgic_init_maintenance_interrupt, NULL, 1);
 +
 +	return kvm_register_device_ops(&kvm_arm_vgic_v2_ops,
 +				       KVM_DEV_TYPE_ARM_VGIC_V2);
 +
 +out_free_irq:
 +	free_percpu_irq(vgic->maint_irq, kvm_get_running_vcpus());
 +	return ret;
 +}

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

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in
arch/arm64/include/asm/kvm_host.h between commit 656473003bc7 ("KVM:
forward declare structs in kvm_types.h") from the kvm tree and commit
6951e48bff0b ("KVM: ARM/arm64: fix non-const declaration of function
returning const") from the kvm-arm 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 arch/arm64/include/asm/kvm_host.h
index be9970a59497,50431d36732b..000000000000
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@@ -43,7 -41,8 +43,7 @@@
  
  #define KVM_VCPU_MAX_FEATURES 3
  
- int kvm_target_cpu(void);
 -struct kvm_vcpu;
+ int __attribute_const__ kvm_target_cpu(void);
  int kvm_reset_vcpu(struct kvm_vcpu *vcpu);
  int kvm_arch_dev_ioctl_check_extension(long ext);
  

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