* [PATCH 05/13] fixup! KVM: selftests: Time guest demand paging
From: Andrew Jones @ 2020-02-14 14:59 UTC (permalink / raw)
To: kvm; +Cc: pbonzini, bgardon, borntraeger, frankja, thuth, peterx
In-Reply-To: <20200214145920.30792-1-drjones@redhat.com>
[Move timespec-diff to test_util.h]
Signed-off-by: Andrew Jones <drjones@redhat.com>
---
.../selftests/kvm/demand_paging_test.c | 42 +++++--------------
.../testing/selftests/kvm/include/test_util.h | 3 ++
tools/testing/selftests/kvm/lib/test_util.c | 20 +++++++++
3 files changed, 34 insertions(+), 31 deletions(-)
diff --git a/tools/testing/selftests/kvm/demand_paging_test.c b/tools/testing/selftests/kvm/demand_paging_test.c
index 2e6e3db8418a..22a3011df62f 100644
--- a/tools/testing/selftests/kvm/demand_paging_test.c
+++ b/tools/testing/selftests/kvm/demand_paging_test.c
@@ -74,26 +74,6 @@ static uint64_t guest_test_phys_mem;
*/
static uint64_t guest_test_virt_mem = DEFAULT_GUEST_TEST_MEM;
-int64_t to_ns(struct timespec ts)
-{
- return (int64_t)ts.tv_nsec + 1000000000LL * (int64_t)ts.tv_sec;
-}
-
-struct timespec diff(struct timespec start, struct timespec end)
-{
- struct timespec temp;
-
- if ((end.tv_nsec-start.tv_nsec) < 0) {
- temp.tv_sec = end.tv_sec - start.tv_sec - 1;
- temp.tv_nsec = 1000000000 + end.tv_nsec - start.tv_nsec;
- } else {
- temp.tv_sec = end.tv_sec - start.tv_sec;
- temp.tv_nsec = end.tv_nsec - start.tv_nsec;
- }
-
- return temp;
-}
-
struct vcpu_args {
uint64_t gva;
uint64_t pages;
@@ -157,8 +137,8 @@ static void *vcpu_worker(void *data)
clock_gettime(CLOCK_MONOTONIC, &end);
PER_VCPU_DEBUG("vCPU %d execution time: %lld.%.9lds\n", vcpu_id,
- (long long)(diff(start, end).tv_sec),
- diff(start, end).tv_nsec);
+ (long long)(timespec_diff(start, end).tv_sec),
+ timespec_diff(start, end).tv_nsec);
return NULL;
}
@@ -226,7 +206,7 @@ static int handle_uffd_page_request(int uffd, uint64_t addr)
clock_gettime(CLOCK_MONOTONIC, &end);
PER_PAGE_DEBUG("UFFDIO_COPY %d \t%lld ns\n", tid,
- (long long)to_ns(diff(start, end)));
+ (long long)timespec_to_ns(timespec_diff(start, end)));
PER_PAGE_DEBUG("Paged in %ld bytes at 0x%lx from thread %d\n",
host_page_size, addr, tid);
@@ -321,10 +301,10 @@ static void *uffd_handler_thread_fn(void *arg)
clock_gettime(CLOCK_MONOTONIC, &end);
PER_VCPU_DEBUG("userfaulted %ld pages over %lld.%.9lds. (%f/sec)\n",
- pages, (long long)(diff(start, end).tv_sec),
- diff(start, end).tv_nsec, pages /
- ((double)diff(start, end).tv_sec +
- (double)diff(start, end).tv_nsec / 100000000.0));
+ pages, (long long)(timespec_diff(start, end).tv_sec),
+ timespec_diff(start, end).tv_nsec, pages /
+ ((double)timespec_diff(start, end).tv_sec +
+ (double)timespec_diff(start, end).tv_nsec / 100000000.0));
return NULL;
}
@@ -432,7 +412,6 @@ static void run_test(enum vm_guest_mode mode, bool use_uffd,
DEBUG("guest physical test memory offset: 0x%lx\n",
guest_test_phys_mem);
-
/* Add an extra memory slot for testing demand paging */
vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS,
guest_test_phys_mem,
@@ -548,10 +527,11 @@ static void run_test(enum vm_guest_mode mode, bool use_uffd,
}
DEBUG("Total guest execution time: %lld.%.9lds\n",
- (long long)(diff(start, end).tv_sec), diff(start, end).tv_nsec);
+ (long long)(timespec_diff(start, end).tv_sec),
+ timespec_diff(start, end).tv_nsec);
DEBUG("Overall demand paging rate: %f pgs/sec\n",
- guest_num_pages / ((double)diff(start, end).tv_sec +
- (double)diff(start, end).tv_nsec / 100000000.0));
+ guest_num_pages / ((double)timespec_diff(start, end).tv_sec +
+ (double)timespec_diff(start, end).tv_nsec / 100000000.0));
ucall_uninit(vm);
kvm_vm_free(vm);
diff --git a/tools/testing/selftests/kvm/include/test_util.h b/tools/testing/selftests/kvm/include/test_util.h
index e696c8219d69..920328ca5f7e 100644
--- a/tools/testing/selftests/kvm/include/test_util.h
+++ b/tools/testing/selftests/kvm/include/test_util.h
@@ -41,4 +41,7 @@ void test_assert(bool exp, const char *exp_str,
size_t parse_size(const char *size);
+int64_t timespec_to_ns(struct timespec ts);
+struct timespec timespec_diff(struct timespec start, struct timespec end);
+
#endif /* SELFTEST_KVM_TEST_UTIL_H */
diff --git a/tools/testing/selftests/kvm/lib/test_util.c b/tools/testing/selftests/kvm/lib/test_util.c
index cbd7f51b07a1..1c0d45afdf36 100644
--- a/tools/testing/selftests/kvm/lib/test_util.c
+++ b/tools/testing/selftests/kvm/lib/test_util.c
@@ -49,3 +49,23 @@ size_t parse_size(const char *size)
return base << shift;
}
+
+int64_t timespec_to_ns(struct timespec ts)
+{
+ return (int64_t)ts.tv_nsec + 1000000000LL * (int64_t)ts.tv_sec;
+}
+
+struct timespec timespec_diff(struct timespec start, struct timespec end)
+{
+ struct timespec temp;
+
+ if ((end.tv_nsec - start.tv_nsec) < 0) {
+ temp.tv_sec = end.tv_sec - start.tv_sec - 1;
+ temp.tv_nsec = 1000000000LL + end.tv_nsec - start.tv_nsec;
+ } else {
+ temp.tv_sec = end.tv_sec - start.tv_sec;
+ temp.tv_nsec = end.tv_nsec - start.tv_nsec;
+ }
+
+ return temp;
+}
--
2.21.1
^ permalink raw reply related
* [PATCH 04/13] fixup! KVM: selftests: Add memory size parameter to the demand paging test
From: Andrew Jones @ 2020-02-14 14:59 UTC (permalink / raw)
To: kvm; +Cc: pbonzini, bgardon, borntraeger, frankja, thuth, peterx
In-Reply-To: <20200214145920.30792-1-drjones@redhat.com>
[Rewrote parse_size() to simplify and provide user more flexibility as
to how sizes are input. Also fixed size overflow assert.]
Signed-off-by: Andrew Jones <drjones@redhat.com>
---
tools/testing/selftests/kvm/lib/test_util.c | 76 +++++++++------------
1 file changed, 33 insertions(+), 43 deletions(-)
diff --git a/tools/testing/selftests/kvm/lib/test_util.c b/tools/testing/selftests/kvm/lib/test_util.c
index 706e0f963a44..cbd7f51b07a1 100644
--- a/tools/testing/selftests/kvm/lib/test_util.c
+++ b/tools/testing/selftests/kvm/lib/test_util.c
@@ -4,58 +4,48 @@
*
* Copyright (C) 2020, Google LLC.
*/
-
-#include "test_util.h"
-
+#include <stdlib.h>
#include <ctype.h>
+#include <limits.h>
+#include "test_util.h"
/*
* Parses "[0-9]+[kmgt]?".
*/
size_t parse_size(const char *size)
{
- size_t len = strlen(size);
- size_t i;
- size_t scale_shift = 0;
size_t base;
-
- TEST_ASSERT(len > 0, "Need at least 1 digit in '%s'", size);
-
- /* Find the first letter in the string, indicating scale. */
- for (i = 0; i < len; i++) {
- if (!isdigit(size[i])) {
- TEST_ASSERT(i > 0, "Need at least 1 digit in '%s'",
- size);
- TEST_ASSERT(i == len - 1,
- "Expected letter at the end in '%s'.",
- size);
- switch (tolower(size[i])) {
- case 't':
- scale_shift = 40;
- break;
- case 'g':
- scale_shift = 30;
- break;
- case 'm':
- scale_shift = 20;
- break;
- case 'k':
- scale_shift = 10;
- break;
- default:
- TEST_ASSERT(false, "Unknown size letter %c",
- size[i]);
- }
- }
+ char *scale;
+ int shift = 0;
+
+ TEST_ASSERT(size && isdigit(size[0]), "Need at least one digit in '%s'", size);
+
+ base = strtoull(size, &scale, 0);
+
+ TEST_ASSERT(base != ULLONG_MAX, "Overflow parsing size!");
+
+ switch (tolower(*scale)) {
+ case 't':
+ shift = 40;
+ break;
+ case 'g':
+ shift = 30;
+ break;
+ case 'm':
+ shift = 20;
+ break;
+ case 'k':
+ shift = 10;
+ break;
+ case 'b':
+ case '\0':
+ shift = 0;
+ break;
+ default:
+ TEST_ASSERT(false, "Unknown size letter %c", *scale);
}
- TEST_ASSERT(scale_shift < 8 * sizeof(size_t),
- "Overflow parsing scale!");
-
- base = atoi(size);
-
- TEST_ASSERT(!(base & ~((1 << (sizeof(size_t) - scale_shift)) - 1)),
- "Overflow parsing size!");
+ TEST_ASSERT((base << shift) >> shift == base, "Overflow scaling size!");
- return base << scale_shift;
+ return base << shift;
}
--
2.21.1
^ permalink raw reply related
* [PATCH 03/13] fixup! KVM: selftests: Support multiple vCPUs in demand paging test
From: Andrew Jones @ 2020-02-14 14:59 UTC (permalink / raw)
To: kvm; +Cc: pbonzini, bgardon, borntraeger, frankja, thuth, peterx
In-Reply-To: <20200214145920.30792-1-drjones@redhat.com>
[guest_code() can't return, use GUEST_ASSERT(). Ensure the number
of guests pages is compatible with the host.]
Signed-off-by: Andrew Jones <drjones@redhat.com>
---
tools/testing/selftests/kvm/demand_paging_test.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/kvm/demand_paging_test.c b/tools/testing/selftests/kvm/demand_paging_test.c
index ec8860b70129..2e6e3db8418a 100644
--- a/tools/testing/selftests/kvm/demand_paging_test.c
+++ b/tools/testing/selftests/kvm/demand_paging_test.c
@@ -115,9 +115,8 @@ static void guest_code(uint32_t vcpu_id)
uint64_t pages;
int i;
- /* Return to signal error if vCPU args data structure is courrupt. */
- if (vcpu_args[vcpu_id].vcpu_id != vcpu_id)
- return;
+ /* Make sure vCPU args data structure is not corrupt. */
+ GUEST_ASSERT(vcpu_args[vcpu_id].vcpu_id == vcpu_id);
gva = vcpu_args[vcpu_id].gva;
pages = vcpu_args[vcpu_id].pages;
@@ -186,6 +185,12 @@ static struct kvm_vm *create_vm(enum vm_guest_mode mode, int vcpus,
pages += ((2 * vcpus * vcpu_memory_bytes) >> PAGE_SHIFT_4K) /
PTES_PER_4K_PT;
+ /*
+ * If the host is uing 64K pages, then we need the number of 4K
+ * guest pages to be a multiple of 16.
+ */
+ pages += 16 - pages % 16;
+
vm = _vm_create(mode, pages, O_RDWR);
kvm_vm_elf_load(vm, program_invocation_name, 0, 0);
#ifdef __x86_64__
--
2.21.1
^ permalink raw reply related
* [PATCH 02/13] fixup! KVM: selftests: Add support for vcpu_args_set to aarch64 and s390x
From: Andrew Jones @ 2020-02-14 14:59 UTC (permalink / raw)
To: kvm; +Cc: pbonzini, bgardon, borntraeger, frankja, thuth, peterx
In-Reply-To: <20200214145920.30792-1-drjones@redhat.com>
[Fixed array index (num => i) and made some style changes.]
Signed-off-by: Andrew Jones <drjones@redhat.com>
---
.../selftests/kvm/lib/aarch64/processor.c | 24 ++++---------------
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/tools/testing/selftests/kvm/lib/aarch64/processor.c b/tools/testing/selftests/kvm/lib/aarch64/processor.c
index 839a76c96f01..f7dffccea12c 100644
--- a/tools/testing/selftests/kvm/lib/aarch64/processor.c
+++ b/tools/testing/selftests/kvm/lib/aarch64/processor.c
@@ -334,36 +334,20 @@ void vm_vcpu_add_default(struct kvm_vm *vm, uint32_t vcpuid, void *guest_code)
aarch64_vcpu_add_default(vm, vcpuid, NULL, guest_code);
}
-/* VM VCPU Args Set
- *
- * Input Args:
- * vm - Virtual Machine
- * vcpuid - VCPU ID
- * num - number of arguments
- * ... - arguments, each of type uint64_t
- *
- * Output Args: None
- *
- * Return: None
- *
- * Sets the first num function input arguments to the values
- * given as variable args. Each of the variable args is expected to
- * be of type uint64_t. The registers set by this function are r0-r7.
- */
void vcpu_args_set(struct kvm_vm *vm, uint32_t vcpuid, unsigned int num, ...)
{
va_list ap;
int i;
TEST_ASSERT(num >= 1 && num <= 8, "Unsupported number of args,\n"
- " num: %u\n",
- num);
+ " num: %u\n", num);
va_start(ap, num);
- for (i = 0; i < num; i++)
- set_reg(vm, vcpuid, ARM64_CORE_REG(regs.regs[num]),
+ for (i = 0; i < num; i++) {
+ set_reg(vm, vcpuid, ARM64_CORE_REG(regs.regs[i]),
va_arg(ap, uint64_t));
+ }
va_end(ap);
}
--
2.21.1
^ permalink raw reply related
* [PATCH 01/13] HACK: Ensure __NR_userfaultfd is defined
From: Andrew Jones @ 2020-02-14 14:59 UTC (permalink / raw)
To: kvm; +Cc: pbonzini, bgardon, borntraeger, frankja, thuth, peterx
In-Reply-To: <20200214145920.30792-1-drjones@redhat.com>
Without this hack kvm/queue kvm selftests don't compile for x86_64.
---
tools/testing/selftests/kvm/demand_paging_test.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/testing/selftests/kvm/demand_paging_test.c b/tools/testing/selftests/kvm/demand_paging_test.c
index df1fc38b4df1..ec8860b70129 100644
--- a/tools/testing/selftests/kvm/demand_paging_test.c
+++ b/tools/testing/selftests/kvm/demand_paging_test.c
@@ -20,6 +20,10 @@
#include <linux/bitops.h>
#include <linux/userfaultfd.h>
+#ifndef __NR_userfaultfd
+#define __NR_userfaultfd 282
+#endif
+
#include "test_util.h"
#include "kvm_util.h"
#include "processor.h"
--
2.21.1
^ permalink raw reply related
* [PATCH 00/13] KVM: selftests: Various fixes and cleanups
From: Andrew Jones @ 2020-02-14 14:59 UTC (permalink / raw)
To: kvm; +Cc: pbonzini, bgardon, borntraeger, frankja, thuth, peterx
This series has several parts:
* First, a hack to get x86 to compile. The missing __NR_userfaultfd
define should be fixed a better way.
* Then, fixups for several commits in kvm/queue. These fixups correspond
to review comments that didn't have a chance to get addressed before
the commits were applied.
* Next, a few unnecessary #define/#ifdef deletions.
* Then, a rework of debug and info message printing.
* Finally, an addition to the API, num-pages conversion utilities,
which cleans up all the num-pages calculations.
Andrew Jones (13):
HACK: Ensure __NR_userfaultfd is defined
fixup! KVM: selftests: Add support for vcpu_args_set to aarch64 and
s390x
fixup! KVM: selftests: Support multiple vCPUs in demand paging test
fixup! KVM: selftests: Add memory size parameter to the demand paging
test
fixup! KVM: selftests: Time guest demand paging
KVM: selftests: Remove unnecessary defines
KVM: selftests: aarch64: Remove unnecessary ifdefs
KVM: selftests: aarch64: Use stream when given
KVM: selftests: Rework debug message printing
KVM: selftests: Convert some printf's to pr_info's
KVM: selftests: Rename vm_guest_mode_params
KVM: selftests: Introduce vm_guest_mode_params
KVM: selftests: Introduce num-pages conversion utilities
.../selftests/kvm/demand_paging_test.c | 148 ++++++++----------
tools/testing/selftests/kvm/dirty_log_test.c | 78 +++++----
.../testing/selftests/kvm/include/kvm_util.h | 14 +-
.../testing/selftests/kvm/include/test_util.h | 18 +++
.../selftests/kvm/kvm_create_max_vcpus.c | 8 +-
.../selftests/kvm/lib/aarch64/processor.c | 30 +---
tools/testing/selftests/kvm/lib/kvm_util.c | 89 +++++++----
.../selftests/kvm/lib/kvm_util_internal.h | 11 --
tools/testing/selftests/kvm/lib/test_util.c | 90 ++++++-----
tools/testing/selftests/kvm/s390x/resets.c | 6 +-
.../selftests/kvm/x86_64/mmio_warning_test.c | 2 +-
tools/testing/selftests/kvm/x86_64/smm_test.c | 2 +-
.../testing/selftests/kvm/x86_64/state_test.c | 2 +-
.../kvm/x86_64/vmx_tsc_adjust_test.c | 4 +-
.../selftests/kvm/x86_64/xss_msr_test.c | 2 +-
15 files changed, 258 insertions(+), 246 deletions(-)
--
2.21.1
^ permalink raw reply
* [PATCH v4 01/20] irqchip/gic-v4.1: Skip absent CPUs while iterating over redistributors
From: Marc Zyngier @ 2020-02-14 14:57 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, kvm, linux-kernel
Cc: Lorenzo Pieralisi, Jason Cooper, Robert Richter, Thomas Gleixner,
Zenghui Yu, Eric Auger, James Morse, Julien Thierry,
Suzuki K Poulose
In-Reply-To: <20200214145736.18550-1-maz@kernel.org>
In a system that is only sparsly populated with CPUs, we can end-up with
redistributors structures that are not initialized. Let's make sure we
don't try and access those when iterating over them (in this case when
checking we have a L2 VPE table).
Fixes: 4e6437f12d6e ("irqchip/gic-v4.1: Ensure L2 vPE table is allocated at RD level")
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
drivers/irqchip/irq-gic-v3-its.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 83b1186ffcad..da883a691028 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -2452,6 +2452,10 @@ static bool allocate_vpe_l2_table(int cpu, u32 id)
if (!gic_rdists->has_rvpeid)
return true;
+ /* Skip non-present CPUs */
+ if (!base)
+ return true;
+
val = gicr_read_vpropbaser(base + SZ_128K + GICR_VPROPBASER);
esz = FIELD_GET(GICR_VPROPBASER_4_1_ENTRY_SIZE, val) + 1;
--
2.20.1
^ permalink raw reply related
* [PATCH v4 00/20] irqchip/gic-v4: GICv4.1 architecture support
From: Marc Zyngier @ 2020-02-14 14:57 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, kvm, linux-kernel
Cc: Lorenzo Pieralisi, Jason Cooper, Robert Richter, Thomas Gleixner,
Zenghui Yu, Eric Auger, James Morse, Julien Thierry,
Suzuki K Poulose
This (now shorter) series expands the existing GICv4 support to deal
with the new GICv4.1 architecture, which comes with a set of major
improvements compared to v4.0:
- One architectural doorbell per vcpu, instead of one doorbell per VLPI
- Doorbell entirely managed by the HW, with an "at most once" delivery
guarantee per non-residency phase and only when requested by the
hypervisor
- A shared memory scheme between ITSs and redistributors, allowing for an
optimised residency sequence (the use of VMOVP becomes less frequent)
- Support for direct virtual SGI delivery (the injection path still involves
the hypervisor), at the cost of losing the active state on SGIs. It
shouldn't be a big deal, but some guest operating systems might notice
(Linux definitely won't care).
On the other hand, public documentation is not available yet, so that's a
bit annoying...
The series is roughly organised in 3 parts:
(1) v4.1 doorbell management
(2) Virtual SGI support
(3) Plumbing of virtual SGIs in KVM
Notes:
- The whole thing is tested on a FVP model, which can be obtained
free of charge on ARM's developer website. It requires you to
create an account, unfortunately... You'll need a fix for the
devicetree that is in the kernel tree (should be merged before
the 5.6 release).
- This series has uncovered a behaviour that looks like a HW bug on
the Cavium ThunderX (aka TX1) platform. I'd very much welcome some
clarification from the Marvell/Cavium folks on Cc, as well as an
official erratum number if this happens to be an actual bug.
[v3 update]
People have ignored for two months now, and it is fairly obvious
that support for this machine is slowly bit-rotting. Maybe I'll
drop the patch and instead start the process of removing all TX1
support from the kernel (we'd certainly be better off without it).
[v4 update]
TX1 is now broken in mainline, and nobody cares. Make of this what
you want.
* From v3 [3]:
- Rebased on v5.6-rc1
- Considerably smaller thanks to the initial patches being merged
- Small bug fix after the v5.6 merge window
* From v2 [2]:
- Another bunch of fixes thanks to Zenghui Yu's very careful review
- HW-accelerated SGIs are now optional thanks to new architected
discovery/selection bits exposed by KVM and used by the guest kernel
- Rebased on v5.5-rc2
* From v1 [1]:
- A bunch of minor reworks after Zenghui Yu's review
- A workaround for what looks like a new and unexpected TX1 bug
- A subtle reorder of the series so that some patches can go in early
[1] https://lore.kernel.org/lkml/20190923182606.32100-1-maz@kernel.org/
[2] https://lore.kernel.org/lkml/20191027144234.8395-1-maz@kernel.org/
[3] https://lore.kernel.org/r/20191224111055.11836-1-maz@kernel.org/
Marc Zyngier (20):
irqchip/gic-v4.1: Skip absent CPUs while iterating over redistributors
irqchip/gic-v3: Use SGIs without active state if offered
irqchip/gic-v4.1: Advertise support v4.1 to KVM
irqchip/gic-v4.1: Map the ITS SGIR register page
irqchip/gic-v4.1: Plumb skeletal VSGI irqchip
irqchip/gic-v4.1: Add initial SGI configuration
irqchip/gic-v4.1: Plumb mask/unmask SGI callbacks
irqchip/gic-v4.1: Plumb get/set_irqchip_state SGI callbacks
irqchip/gic-v4.1: Plumb set_vcpu_affinity SGI callbacks
irqchip/gic-v4.1: Move doorbell management to the GICv4 abstraction
layer
irqchip/gic-v4.1: Add VSGI allocation/teardown
irqchip/gic-v4.1: Add VSGI property setup
irqchip/gic-v4.1: Eagerly vmap vPEs
KVM: arm64: GICv4.1: Let doorbells be auto-enabled
KVM: arm64: GICv4.1: Add direct injection capability to SGI registers
KVM: arm64: GICv4.1: Allow SGIs to switch between HW and SW interrupts
KVM: arm64: GICv4.1: Plumb SGI implementation selection in the
distributor
KVM: arm64: GICv4.1: Reload VLPI configuration on distributor
enable/disable
KVM: arm64: GICv4.1: Allow non-trapping WFI when using HW SGIs
KVM: arm64: GICv4.1: Expose HW-based SGIs in debugfs
arch/arm/include/asm/kvm_host.h | 1 +
arch/arm64/include/asm/kvm_emulate.h | 3 +-
arch/arm64/include/asm/kvm_host.h | 1 +
drivers/irqchip/irq-gic-v3-its.c | 301 ++++++++++++++++++++++++-
drivers/irqchip/irq-gic-v3.c | 12 +-
drivers/irqchip/irq-gic-v4.c | 134 ++++++++++-
include/kvm/arm_vgic.h | 4 +
include/linux/irqchip/arm-gic-common.h | 2 +
include/linux/irqchip/arm-gic-v3.h | 19 +-
include/linux/irqchip/arm-gic-v4.h | 20 +-
virt/kvm/arm/arm.c | 8 +
virt/kvm/arm/vgic/vgic-debug.c | 14 +-
virt/kvm/arm/vgic/vgic-mmio-v3.c | 68 +++++-
virt/kvm/arm/vgic/vgic-mmio.c | 88 +++++++-
virt/kvm/arm/vgic/vgic-v3.c | 6 +-
virt/kvm/arm/vgic/vgic-v4.c | 139 ++++++++++--
virt/kvm/arm/vgic/vgic.h | 1 +
17 files changed, 763 insertions(+), 58 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH v4 02/20] irqchip/gic-v3: Use SGIs without active state if offered
From: Marc Zyngier @ 2020-02-14 14:57 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, kvm, linux-kernel
Cc: Lorenzo Pieralisi, Jason Cooper, Robert Richter, Thomas Gleixner,
Zenghui Yu, Eric Auger, James Morse, Julien Thierry,
Suzuki K Poulose
In-Reply-To: <20200214145736.18550-1-maz@kernel.org>
To allow the direct injection of SGIs into a guest, the GICv4.1
architecture has to sacrifice the Active state so that SGIs look
a lot like LPIs (they are injected by the same mechanism).
In order not to break existing software, the architecture gives
offers guests OSs the choice: SGIs with or without an active
state. It is the hypervisors duty to honor the guest's choice.
For this, the architecture offers a discovery bit indicating whether
the GIC supports GICv4.1 SGIs (GICD_TYPER2.nASSGIcap), and another
bit indicating whether the guest wants Active-less SGIs or not
(controlled by GICD_CTLR.nASSGIreq).
A hypervisor not supporting GICv4.1 SGIs would leave nASSGIcap
clear, and a guest not knowing about GICv4.1 SGIs (or definitely
wanting an Active state) would leave nASSGIreq clear (both being
thankfully backward compatible with oler revisions of the GIC).
Since Linux is perfectly happy without an active state on SGIs,
inform the hypervisor that we'll use that if offered.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
drivers/irqchip/irq-gic-v3.c | 10 ++++++++--
include/linux/irqchip/arm-gic-v3.h | 2 ++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index cd76435c4a31..73e87e176d76 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -724,6 +724,7 @@ static void __init gic_dist_init(void)
unsigned int i;
u64 affinity;
void __iomem *base = gic_data.dist_base;
+ u32 val;
/* Disable the distributor */
writel_relaxed(0, base + GICD_CTLR);
@@ -756,9 +757,14 @@ static void __init gic_dist_init(void)
/* Now do the common stuff, and wait for the distributor to drain */
gic_dist_config(base, GIC_LINE_NR, gic_dist_wait_for_rwp);
+ val = GICD_CTLR_ARE_NS | GICD_CTLR_ENABLE_G1A | GICD_CTLR_ENABLE_G1;
+ if (gic_data.rdists.gicd_typer2 & GICD_TYPER2_nASSGIcap) {
+ pr_info("Enabling SGIs without active state\n");
+ val |= GICD_CTLR_nASSGIreq;
+ }
+
/* Enable distributor with ARE, Group1 */
- writel_relaxed(GICD_CTLR_ARE_NS | GICD_CTLR_ENABLE_G1A | GICD_CTLR_ENABLE_G1,
- base + GICD_CTLR);
+ writel_relaxed(val, base + GICD_CTLR);
/*
* Set all global interrupts to the boot CPU only. ARE must be
diff --git a/include/linux/irqchip/arm-gic-v3.h b/include/linux/irqchip/arm-gic-v3.h
index 83439bfb6c5b..c29a02678a6f 100644
--- a/include/linux/irqchip/arm-gic-v3.h
+++ b/include/linux/irqchip/arm-gic-v3.h
@@ -57,6 +57,7 @@
#define GICD_SPENDSGIR 0x0F20
#define GICD_CTLR_RWP (1U << 31)
+#define GICD_CTLR_nASSGIreq (1U << 8)
#define GICD_CTLR_DS (1U << 6)
#define GICD_CTLR_ARE_NS (1U << 4)
#define GICD_CTLR_ENABLE_G1A (1U << 1)
@@ -90,6 +91,7 @@
#define GICD_TYPER_ESPIS(typer) \
(((typer) & GICD_TYPER_ESPI) ? GICD_TYPER_SPIS((typer) >> 27) : 0)
+#define GICD_TYPER2_nASSGIcap (1U << 8)
#define GICD_TYPER2_VIL (1U << 7)
#define GICD_TYPER2_VID GENMASK(4, 0)
--
2.20.1
^ permalink raw reply related
* [PATCH v4 04/20] irqchip/gic-v4.1: Map the ITS SGIR register page
From: Marc Zyngier @ 2020-02-14 14:57 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, kvm, linux-kernel
Cc: Lorenzo Pieralisi, Jason Cooper, Robert Richter, Thomas Gleixner,
Zenghui Yu, Eric Auger, James Morse, Julien Thierry,
Suzuki K Poulose
In-Reply-To: <20200214145736.18550-1-maz@kernel.org>
One of the new features of GICv4.1 is to allow virtual SGIs to be
directly signaled to a VPE. For that, the ITS has grown a new
64kB page containing only a single register that is used to
signal a SGI to a given VPE.
Add a second mapping covering this new 64kB range, and take this
opportunity to limit the original mapping to 64kB, which is enough
to cover the span of the ITS registers.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
drivers/irqchip/irq-gic-v3-its.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 9a7854416b89..d6201443b406 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -96,6 +96,7 @@ struct its_node {
struct mutex dev_alloc_lock;
struct list_head entry;
void __iomem *base;
+ void __iomem *sgir_base;
phys_addr_t phys_base;
struct its_cmd_block *cmd_base;
struct its_cmd_block *cmd_write;
@@ -4408,7 +4409,7 @@ static int __init its_probe_one(struct resource *res,
struct page *page;
int err;
- its_base = ioremap(res->start, resource_size(res));
+ its_base = ioremap(res->start, SZ_64K);
if (!its_base) {
pr_warn("ITS@%pa: Unable to map ITS registers\n", &res->start);
return -ENOMEM;
@@ -4459,6 +4460,13 @@ static int __init its_probe_one(struct resource *res,
if (is_v4_1(its)) {
u32 svpet = FIELD_GET(GITS_TYPER_SVPET, typer);
+
+ its->sgir_base = ioremap(res->start + SZ_128K, SZ_64K);
+ if (!its->sgir_base) {
+ err = -ENOMEM;
+ goto out_free_its;
+ }
+
its->mpidr = readl_relaxed(its_base + GITS_MPIDR);
pr_info("ITS@%pa: Using GICv4.1 mode %08x %08x\n",
@@ -4472,7 +4480,7 @@ static int __init its_probe_one(struct resource *res,
get_order(ITS_CMD_QUEUE_SZ));
if (!page) {
err = -ENOMEM;
- goto out_free_its;
+ goto out_unmap_sgir;
}
its->cmd_base = (void *)page_address(page);
its->cmd_write = its->cmd_base;
@@ -4539,6 +4547,9 @@ static int __init its_probe_one(struct resource *res,
its_free_tables(its);
out_free_cmd:
free_pages((unsigned long)its->cmd_base, get_order(ITS_CMD_QUEUE_SZ));
+out_unmap_sgir:
+ if (its->sgir_base)
+ iounmap(its->sgir_base);
out_free_its:
kfree(its);
out_unmap:
--
2.20.1
^ permalink raw reply related
* [PATCH v4 03/20] irqchip/gic-v4.1: Advertise support v4.1 to KVM
From: Marc Zyngier @ 2020-02-14 14:57 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, kvm, linux-kernel
Cc: Lorenzo Pieralisi, Jason Cooper, Robert Richter, Thomas Gleixner,
Zenghui Yu, Eric Auger, James Morse, Julien Thierry,
Suzuki K Poulose
In-Reply-To: <20200214145736.18550-1-maz@kernel.org>
Tell KVM that we support v4.1. Nothing uses this information so far.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
drivers/irqchip/irq-gic-v3-its.c | 9 ++++++++-
drivers/irqchip/irq-gic-v3.c | 2 ++
include/linux/irqchip/arm-gic-common.h | 2 ++
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index da883a691028..9a7854416b89 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -4822,6 +4822,7 @@ int __init its_init(struct fwnode_handle *handle, struct rdists *rdists,
struct device_node *of_node;
struct its_node *its;
bool has_v4 = false;
+ bool has_v4_1 = false;
int err;
gic_rdists = rdists;
@@ -4842,8 +4843,14 @@ int __init its_init(struct fwnode_handle *handle, struct rdists *rdists,
if (err)
return err;
- list_for_each_entry(its, &its_nodes, entry)
+ list_for_each_entry(its, &its_nodes, entry) {
has_v4 |= is_v4(its);
+ has_v4_1 |= is_v4_1(its);
+ }
+
+ /* Don't bother with inconsistent systems */
+ if (WARN_ON(!has_v4_1 && rdists->has_rvpeid))
+ rdists->has_rvpeid = false;
if (has_v4 & rdists->has_vlpis) {
if (its_init_vpe_domain() ||
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 73e87e176d76..5b192c0b6b57 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -1784,6 +1784,7 @@ static void __init gic_of_setup_kvm_info(struct device_node *node)
gic_v3_kvm_info.vcpu = r;
gic_v3_kvm_info.has_v4 = gic_data.rdists.has_vlpis;
+ gic_v3_kvm_info.has_v4_1 = gic_data.rdists.has_rvpeid;
gic_set_kvm_info(&gic_v3_kvm_info);
}
@@ -2099,6 +2100,7 @@ static void __init gic_acpi_setup_kvm_info(void)
}
gic_v3_kvm_info.has_v4 = gic_data.rdists.has_vlpis;
+ gic_v3_kvm_info.has_v4_1 = gic_data.rdists.has_rvpeid;
gic_set_kvm_info(&gic_v3_kvm_info);
}
diff --git a/include/linux/irqchip/arm-gic-common.h b/include/linux/irqchip/arm-gic-common.h
index b9850f5f1906..fa8c0455c352 100644
--- a/include/linux/irqchip/arm-gic-common.h
+++ b/include/linux/irqchip/arm-gic-common.h
@@ -32,6 +32,8 @@ struct gic_kvm_info {
struct resource vctrl;
/* vlpi support */
bool has_v4;
+ /* rvpeid support */
+ bool has_v4_1;
};
const struct gic_kvm_info *gic_get_kvm_info(void);
--
2.20.1
^ permalink raw reply related
* [PATCH v4 07/20] irqchip/gic-v4.1: Plumb mask/unmask SGI callbacks
From: Marc Zyngier @ 2020-02-14 14:57 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, kvm, linux-kernel
Cc: Lorenzo Pieralisi, Jason Cooper, Robert Richter, Thomas Gleixner,
Zenghui Yu, Eric Auger, James Morse, Julien Thierry,
Suzuki K Poulose
In-Reply-To: <20200214145736.18550-1-maz@kernel.org>
Implement mask/unmask for virtual SGIs by calling into the
configuration helper.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
drivers/irqchip/irq-gic-v3-its.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 229e4ae9c59b..1e448d9a16ea 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -3892,6 +3892,22 @@ static void its_configure_sgi(struct irq_data *d, bool clear)
its_send_single_vcommand(find_4_1_its(), its_build_vsgi_cmd, &desc);
}
+static void its_sgi_mask_irq(struct irq_data *d)
+{
+ struct its_vpe *vpe = irq_data_get_irq_chip_data(d);
+
+ vpe->sgi_config[d->hwirq].enabled = false;
+ its_configure_sgi(d, false);
+}
+
+static void its_sgi_unmask_irq(struct irq_data *d)
+{
+ struct its_vpe *vpe = irq_data_get_irq_chip_data(d);
+
+ vpe->sgi_config[d->hwirq].enabled = true;
+ its_configure_sgi(d, false);
+}
+
static int its_sgi_set_affinity(struct irq_data *d,
const struct cpumask *mask_val,
bool force)
@@ -3901,6 +3917,8 @@ static int its_sgi_set_affinity(struct irq_data *d,
static struct irq_chip its_sgi_irq_chip = {
.name = "GICv4.1-sgi",
+ .irq_mask = its_sgi_mask_irq,
+ .irq_unmask = its_sgi_unmask_irq,
.irq_set_affinity = its_sgi_set_affinity,
};
--
2.20.1
^ permalink raw reply related
* [PATCH v4 06/20] irqchip/gic-v4.1: Add initial SGI configuration
From: Marc Zyngier @ 2020-02-14 14:57 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, kvm, linux-kernel
Cc: Lorenzo Pieralisi, Jason Cooper, Robert Richter, Thomas Gleixner,
Zenghui Yu, Eric Auger, James Morse, Julien Thierry,
Suzuki K Poulose
In-Reply-To: <20200214145736.18550-1-maz@kernel.org>
The GICv4.1 ITS has yet another new command (VSGI) which allows
a VPE-targeted SGI to be configured (or have its pending state
cleared). Add support for this command and plumb it into the
activate irqdomain callback so that it is ready to be used.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
drivers/irqchip/irq-gic-v3-its.c | 76 +++++++++++++++++++++++++++++-
include/linux/irqchip/arm-gic-v3.h | 3 +-
2 files changed, 77 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 6121c8f2a8ce..229e4ae9c59b 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -354,6 +354,15 @@ struct its_cmd_desc {
struct {
struct its_vpe *vpe;
} its_invdb_cmd;
+
+ struct {
+ struct its_vpe *vpe;
+ u8 sgi;
+ u8 priority;
+ bool enable;
+ bool group;
+ bool clear;
+ } its_vsgi_cmd;
};
};
@@ -502,6 +511,31 @@ static void its_encode_db(struct its_cmd_block *cmd, bool db)
its_mask_encode(&cmd->raw_cmd[2], db, 63, 63);
}
+static void its_encode_sgi_intid(struct its_cmd_block *cmd, u8 sgi)
+{
+ its_mask_encode(&cmd->raw_cmd[0], sgi, 35, 32);
+}
+
+static void its_encode_sgi_priority(struct its_cmd_block *cmd, u8 prio)
+{
+ its_mask_encode(&cmd->raw_cmd[0], prio >> 4, 23, 20);
+}
+
+static void its_encode_sgi_group(struct its_cmd_block *cmd, bool grp)
+{
+ its_mask_encode(&cmd->raw_cmd[0], grp, 10, 10);
+}
+
+static void its_encode_sgi_clear(struct its_cmd_block *cmd, bool clr)
+{
+ its_mask_encode(&cmd->raw_cmd[0], clr, 9, 9);
+}
+
+static void its_encode_sgi_enable(struct its_cmd_block *cmd, bool en)
+{
+ its_mask_encode(&cmd->raw_cmd[0], en, 8, 8);
+}
+
static inline void its_fixup_cmd(struct its_cmd_block *cmd)
{
/* Let's fixup BE commands */
@@ -867,6 +901,26 @@ static struct its_vpe *its_build_invdb_cmd(struct its_node *its,
return valid_vpe(its, desc->its_invdb_cmd.vpe);
}
+static struct its_vpe *its_build_vsgi_cmd(struct its_node *its,
+ struct its_cmd_block *cmd,
+ struct its_cmd_desc *desc)
+{
+ if (WARN_ON(!is_v4_1(its)))
+ return NULL;
+
+ its_encode_cmd(cmd, GITS_CMD_VSGI);
+ its_encode_vpeid(cmd, desc->its_vsgi_cmd.vpe->vpe_id);
+ its_encode_sgi_intid(cmd, desc->its_vsgi_cmd.sgi);
+ its_encode_sgi_priority(cmd, desc->its_vsgi_cmd.priority);
+ its_encode_sgi_group(cmd, desc->its_vsgi_cmd.group);
+ its_encode_sgi_clear(cmd, desc->its_vsgi_cmd.clear);
+ its_encode_sgi_enable(cmd, desc->its_vsgi_cmd.enable);
+
+ its_fixup_cmd(cmd);
+
+ return valid_vpe(its, desc->its_vsgi_cmd.vpe);
+}
+
static u64 its_cmd_ptr_to_offset(struct its_node *its,
struct its_cmd_block *ptr)
{
@@ -3823,6 +3877,21 @@ static struct irq_chip its_vpe_4_1_irq_chip = {
.irq_set_vcpu_affinity = its_vpe_4_1_set_vcpu_affinity,
};
+static void its_configure_sgi(struct irq_data *d, bool clear)
+{
+ struct its_vpe *vpe = irq_data_get_irq_chip_data(d);
+ struct its_cmd_desc desc;
+
+ desc.its_vsgi_cmd.vpe = vpe;
+ desc.its_vsgi_cmd.sgi = d->hwirq;
+ desc.its_vsgi_cmd.priority = vpe->sgi_config[d->hwirq].priority;
+ desc.its_vsgi_cmd.enable = vpe->sgi_config[d->hwirq].enabled;
+ desc.its_vsgi_cmd.group = vpe->sgi_config[d->hwirq].group;
+ desc.its_vsgi_cmd.clear = clear;
+
+ its_send_single_vcommand(find_4_1_its(), its_build_vsgi_cmd, &desc);
+}
+
static int its_sgi_set_affinity(struct irq_data *d,
const struct cpumask *mask_val,
bool force)
@@ -3868,13 +3937,18 @@ static void its_sgi_irq_domain_free(struct irq_domain *domain,
static int its_sgi_irq_domain_activate(struct irq_domain *domain,
struct irq_data *d, bool reserve)
{
+ /* Write out the initial SGI configuration */
+ its_configure_sgi(d, false);
return 0;
}
static void its_sgi_irq_domain_deactivate(struct irq_domain *domain,
struct irq_data *d)
{
- /* Nothing to do */
+ struct its_vpe *vpe = irq_data_get_irq_chip_data(d);
+
+ vpe->sgi_config[d->hwirq].enabled = false;
+ its_configure_sgi(d, true);
}
static struct irq_domain_ops its_sgi_domain_ops = {
diff --git a/include/linux/irqchip/arm-gic-v3.h b/include/linux/irqchip/arm-gic-v3.h
index c29a02678a6f..a89578884263 100644
--- a/include/linux/irqchip/arm-gic-v3.h
+++ b/include/linux/irqchip/arm-gic-v3.h
@@ -502,8 +502,9 @@
#define GITS_CMD_VMAPTI GITS_CMD_GICv4(GITS_CMD_MAPTI)
#define GITS_CMD_VMOVI GITS_CMD_GICv4(GITS_CMD_MOVI)
#define GITS_CMD_VSYNC GITS_CMD_GICv4(GITS_CMD_SYNC)
-/* VMOVP and INVDB are the odd ones, as they dont have a physical counterpart */
+/* VMOVP, VSGI and INVDB are the odd ones, as they dont have a physical counterpart */
#define GITS_CMD_VMOVP GITS_CMD_GICv4(2)
+#define GITS_CMD_VSGI GITS_CMD_GICv4(3)
#define GITS_CMD_INVDB GITS_CMD_GICv4(0xe)
/*
--
2.20.1
^ permalink raw reply related
* [PATCH v4 05/20] irqchip/gic-v4.1: Plumb skeletal VSGI irqchip
From: Marc Zyngier @ 2020-02-14 14:57 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, kvm, linux-kernel
Cc: Lorenzo Pieralisi, Jason Cooper, Robert Richter, Thomas Gleixner,
Zenghui Yu, Eric Auger, James Morse, Julien Thierry,
Suzuki K Poulose
In-Reply-To: <20200214145736.18550-1-maz@kernel.org>
Since GICv4.1 has the capability to inject 16 SGIs into each VPE,
and that I'm keen not to invent too many specific interfaces to
manupulate these interrupts, let's pretend that each of these SGIs
is an actual Linux interrupt.
For that matter, let's introduce a minimal irqchip and irqdomain
setup that will get fleshed up in the following patches.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
drivers/irqchip/irq-gic-v3-its.c | 68 +++++++++++++++++++++++++++++-
drivers/irqchip/irq-gic-v4.c | 8 +++-
include/linux/irqchip/arm-gic-v4.h | 9 +++-
3 files changed, 81 insertions(+), 4 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index d6201443b406..6121c8f2a8ce 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -3823,6 +3823,67 @@ static struct irq_chip its_vpe_4_1_irq_chip = {
.irq_set_vcpu_affinity = its_vpe_4_1_set_vcpu_affinity,
};
+static int its_sgi_set_affinity(struct irq_data *d,
+ const struct cpumask *mask_val,
+ bool force)
+{
+ return -EINVAL;
+}
+
+static struct irq_chip its_sgi_irq_chip = {
+ .name = "GICv4.1-sgi",
+ .irq_set_affinity = its_sgi_set_affinity,
+};
+
+static int its_sgi_irq_domain_alloc(struct irq_domain *domain,
+ unsigned int virq, unsigned int nr_irqs,
+ void *args)
+{
+ struct its_vpe *vpe = args;
+ int i;
+
+ /* Yes, we do want 16 SGIs */
+ WARN_ON(nr_irqs != 16);
+
+ for (i = 0; i < 16; i++) {
+ vpe->sgi_config[i].priority = 0;
+ vpe->sgi_config[i].enabled = false;
+ vpe->sgi_config[i].group = false;
+
+ irq_domain_set_hwirq_and_chip(domain, virq + i, i,
+ &its_sgi_irq_chip, vpe);
+ irq_set_status_flags(virq + i, IRQ_DISABLE_UNLAZY);
+ }
+
+ return 0;
+}
+
+static void its_sgi_irq_domain_free(struct irq_domain *domain,
+ unsigned int virq,
+ unsigned int nr_irqs)
+{
+ /* Nothing to do */
+}
+
+static int its_sgi_irq_domain_activate(struct irq_domain *domain,
+ struct irq_data *d, bool reserve)
+{
+ return 0;
+}
+
+static void its_sgi_irq_domain_deactivate(struct irq_domain *domain,
+ struct irq_data *d)
+{
+ /* Nothing to do */
+}
+
+static struct irq_domain_ops its_sgi_domain_ops = {
+ .alloc = its_sgi_irq_domain_alloc,
+ .free = its_sgi_irq_domain_free,
+ .activate = its_sgi_irq_domain_activate,
+ .deactivate = its_sgi_irq_domain_deactivate,
+};
+
static int its_vpe_id_alloc(void)
{
return ida_simple_get(&its_vpeid_ida, 0, ITS_MAX_VPEID, GFP_KERNEL);
@@ -4864,8 +4925,13 @@ int __init its_init(struct fwnode_handle *handle, struct rdists *rdists,
rdists->has_rvpeid = false;
if (has_v4 & rdists->has_vlpis) {
+ struct irq_domain_ops *sgi_ops = NULL;
+
+ if (has_v4_1)
+ sgi_ops = &its_sgi_domain_ops;
+
if (its_init_vpe_domain() ||
- its_init_v4(parent_domain, &its_vpe_domain_ops)) {
+ its_init_v4(parent_domain, &its_vpe_domain_ops, sgi_ops)) {
rdists->has_vlpis = false;
pr_err("ITS: Disabling GICv4 support\n");
}
diff --git a/drivers/irqchip/irq-gic-v4.c b/drivers/irqchip/irq-gic-v4.c
index 45969927cc81..c01910d53f9e 100644
--- a/drivers/irqchip/irq-gic-v4.c
+++ b/drivers/irqchip/irq-gic-v4.c
@@ -85,6 +85,7 @@
static struct irq_domain *gic_domain;
static const struct irq_domain_ops *vpe_domain_ops;
+static const struct irq_domain_ops *sgi_domain_ops;
int its_alloc_vcpu_irqs(struct its_vm *vm)
{
@@ -216,12 +217,15 @@ int its_prop_update_vlpi(int irq, u8 config, bool inv)
return irq_set_vcpu_affinity(irq, &info);
}
-int its_init_v4(struct irq_domain *domain, const struct irq_domain_ops *ops)
+int its_init_v4(struct irq_domain *domain,
+ const struct irq_domain_ops *vpe_ops,
+ const struct irq_domain_ops *sgi_ops)
{
if (domain) {
pr_info("ITS: Enabling GICv4 support\n");
gic_domain = domain;
- vpe_domain_ops = ops;
+ vpe_domain_ops = vpe_ops;
+ sgi_domain_ops = sgi_ops;
return 0;
}
diff --git a/include/linux/irqchip/arm-gic-v4.h b/include/linux/irqchip/arm-gic-v4.h
index d9c34968467a..30b4855bf766 100644
--- a/include/linux/irqchip/arm-gic-v4.h
+++ b/include/linux/irqchip/arm-gic-v4.h
@@ -49,6 +49,11 @@ struct its_vpe {
};
/* GICv4.1 implementations */
struct {
+ struct {
+ u8 priority;
+ bool enabled;
+ bool group;
+ } sgi_config[16];
atomic_t vmapp_count;
};
};
@@ -118,6 +123,8 @@ int its_unmap_vlpi(int irq);
int its_prop_update_vlpi(int irq, u8 config, bool inv);
struct irq_domain_ops;
-int its_init_v4(struct irq_domain *domain, const struct irq_domain_ops *ops);
+int its_init_v4(struct irq_domain *domain,
+ const struct irq_domain_ops *vpe_ops,
+ const struct irq_domain_ops *sgi_ops);
#endif
--
2.20.1
^ permalink raw reply related
* [PATCH v4 08/20] irqchip/gic-v4.1: Plumb get/set_irqchip_state SGI callbacks
From: Marc Zyngier @ 2020-02-14 14:57 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, kvm, linux-kernel
Cc: Lorenzo Pieralisi, Jason Cooper, Robert Richter, Thomas Gleixner,
Zenghui Yu, Eric Auger, James Morse, Julien Thierry,
Suzuki K Poulose
In-Reply-To: <20200214145736.18550-1-maz@kernel.org>
To implement the get/set_irqchip_state callbacks (limited to the
PENDING state), we have to use a particular set of hacks:
- Reading the pending state is done by using a pair of new redistributor
registers (GICR_VSGIR, GICR_VSGIPENDR), which allow the 16 interrupts
state to be retrieved.
- Setting the pending state is done by generating it as we'd otherwise do
for a guest (writing to GITS_SGIR)
- Clearing the pending state is done by emiting a VSGI command with the
"clear" bit set.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
drivers/irqchip/irq-gic-v3-its.c | 56 ++++++++++++++++++++++++++++++
include/linux/irqchip/arm-gic-v3.h | 14 ++++++++
2 files changed, 70 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 1e448d9a16ea..a9753435c4ff 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -3915,11 +3915,67 @@ static int its_sgi_set_affinity(struct irq_data *d,
return -EINVAL;
}
+static int its_sgi_set_irqchip_state(struct irq_data *d,
+ enum irqchip_irq_state which,
+ bool state)
+{
+ if (which != IRQCHIP_STATE_PENDING)
+ return -EINVAL;
+
+ if (state) {
+ struct its_vpe *vpe = irq_data_get_irq_chip_data(d);
+ struct its_node *its = find_4_1_its();
+ u64 val;
+
+ val = FIELD_PREP(GITS_SGIR_VPEID, vpe->vpe_id);
+ val |= FIELD_PREP(GITS_SGIR_VINTID, d->hwirq);
+ writeq_relaxed(val, its->sgir_base + GITS_SGIR - SZ_128K);
+ } else {
+ its_configure_sgi(d, true);
+ }
+
+ return 0;
+}
+
+static int its_sgi_get_irqchip_state(struct irq_data *d,
+ enum irqchip_irq_state which, bool *val)
+{
+ struct its_vpe *vpe = irq_data_get_irq_chip_data(d);
+ void __iomem *base = gic_data_rdist_cpu(vpe->col_idx)->rd_base + SZ_128K;
+ u32 count = 1000000; /* 1s! */
+ u32 status;
+
+ if (which != IRQCHIP_STATE_PENDING)
+ return -EINVAL;
+
+ writel_relaxed(vpe->vpe_id, base + GICR_VSGIR);
+ do {
+ status = readl_relaxed(base + GICR_VSGIPENDR);
+ if (!(status & GICR_VSGIPENDR_BUSY))
+ goto out;
+
+ count--;
+ if (!count) {
+ pr_err_ratelimited("Unable to get SGI status\n");
+ goto out;
+ }
+ cpu_relax();
+ udelay(1);
+ } while(count);
+
+out:
+ *val = !!(status & (1 << d->hwirq));
+
+ return 0;
+}
+
static struct irq_chip its_sgi_irq_chip = {
.name = "GICv4.1-sgi",
.irq_mask = its_sgi_mask_irq,
.irq_unmask = its_sgi_unmask_irq,
.irq_set_affinity = its_sgi_set_affinity,
+ .irq_set_irqchip_state = its_sgi_set_irqchip_state,
+ .irq_get_irqchip_state = its_sgi_get_irqchip_state,
};
static int its_sgi_irq_domain_alloc(struct irq_domain *domain,
diff --git a/include/linux/irqchip/arm-gic-v3.h b/include/linux/irqchip/arm-gic-v3.h
index a89578884263..64da945486ac 100644
--- a/include/linux/irqchip/arm-gic-v3.h
+++ b/include/linux/irqchip/arm-gic-v3.h
@@ -345,6 +345,15 @@
#define GICR_VPENDBASER_4_1_VGRP1EN (1ULL << 58)
#define GICR_VPENDBASER_4_1_VPEID GENMASK_ULL(15, 0)
+#define GICR_VSGIR 0x0080
+
+#define GICR_VSGIR_VPEID GENMASK(15, 0)
+
+#define GICR_VSGIPENDR 0x0088
+
+#define GICR_VSGIPENDR_BUSY (1U << 31)
+#define GICR_VSGIPENDR_PENDING GENMASK(15, 0)
+
/*
* ITS registers, offsets from ITS_base
*/
@@ -368,6 +377,11 @@
#define GITS_TRANSLATER 0x10040
+#define GITS_SGIR 0x20020
+
+#define GITS_SGIR_VPEID GENMASK_ULL(47, 32)
+#define GITS_SGIR_VINTID GENMASK_ULL(7, 0)
+
#define GITS_CTLR_ENABLE (1U << 0)
#define GITS_CTLR_ImDe (1U << 1)
#define GITS_CTLR_ITS_NUMBER_SHIFT 4
--
2.20.1
^ permalink raw reply related
* [PATCH v4 09/20] irqchip/gic-v4.1: Plumb set_vcpu_affinity SGI callbacks
From: Marc Zyngier @ 2020-02-14 14:57 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, kvm, linux-kernel
Cc: Lorenzo Pieralisi, Jason Cooper, Robert Richter, Thomas Gleixner,
Zenghui Yu, Eric Auger, James Morse, Julien Thierry,
Suzuki K Poulose
In-Reply-To: <20200214145736.18550-1-maz@kernel.org>
As for VLPIs, there is a number of configuration bits that cannot
be directly communicated through the normal irqchip API, and we
have to use our good old friend set_vcpu_affinity.
This is used to configure group and priority for a given vSGI.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
drivers/irqchip/irq-gic-v3-its.c | 18 ++++++++++++++++++
include/linux/irqchip/arm-gic-v4.h | 5 +++++
2 files changed, 23 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index a9753435c4ff..a2e824eae43f 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -3969,6 +3969,23 @@ static int its_sgi_get_irqchip_state(struct irq_data *d,
return 0;
}
+static int its_sgi_set_vcpu_affinity(struct irq_data *d, void *vcpu_info)
+{
+ struct its_vpe *vpe = irq_data_get_irq_chip_data(d);
+ struct its_cmd_info *info = vcpu_info;
+
+ switch (info->cmd_type) {
+ case PROP_UPDATE_SGI:
+ vpe->sgi_config[d->hwirq].priority = info->priority;
+ vpe->sgi_config[d->hwirq].group = info->group;
+ its_configure_sgi(d, false);
+ return 0;
+
+ default:
+ return -EINVAL;
+ }
+}
+
static struct irq_chip its_sgi_irq_chip = {
.name = "GICv4.1-sgi",
.irq_mask = its_sgi_mask_irq,
@@ -3976,6 +3993,7 @@ static struct irq_chip its_sgi_irq_chip = {
.irq_set_affinity = its_sgi_set_affinity,
.irq_set_irqchip_state = its_sgi_set_irqchip_state,
.irq_get_irqchip_state = its_sgi_get_irqchip_state,
+ .irq_set_vcpu_affinity = its_sgi_set_vcpu_affinity,
};
static int its_sgi_irq_domain_alloc(struct irq_domain *domain,
diff --git a/include/linux/irqchip/arm-gic-v4.h b/include/linux/irqchip/arm-gic-v4.h
index 30b4855bf766..a1a9d40266f5 100644
--- a/include/linux/irqchip/arm-gic-v4.h
+++ b/include/linux/irqchip/arm-gic-v4.h
@@ -98,6 +98,7 @@ enum its_vcpu_info_cmd_type {
SCHEDULE_VPE,
DESCHEDULE_VPE,
INVALL_VPE,
+ PROP_UPDATE_SGI,
};
struct its_cmd_info {
@@ -110,6 +111,10 @@ struct its_cmd_info {
bool g0en;
bool g1en;
};
+ struct {
+ u8 priority;
+ bool group;
+ };
};
};
--
2.20.1
^ permalink raw reply related
* [PATCH] kvm: x86: Print "disabled by bios" only once per host
From: Erwan Velu @ 2020-02-14 14:30 UTC (permalink / raw)
Cc: Erwan Velu, Paolo Bonzini, Sean Christopherson, Vitaly Kuznetsov,
Wanpeng Li, Jim Mattson, Joerg Roedel, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, x86, kvm,
linux-kernel
The current behavior is to print a "disabled by bios" message per CPU thread.
As modern CPUs can have up to 64 cores, 128 on a dual socket, and turns this
printk to be a pretty noisy by showing up to 256 times the same line in a row.
This patch offer to only print the message once per host considering the BIOS will
disabled the feature for all sockets/cores at once and not on a per core basis.
Signed-off-by: Erwan Velu <e.velu@criteo.com>
---
arch/x86/kvm/x86.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index fbabb2f06273..8f0d7a09d453 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7300,7 +7300,7 @@ int kvm_arch_init(void *opaque)
goto out;
}
if (ops->disabled_by_bios()) {
- printk(KERN_ERR "kvm: disabled by bios\n");
+ printk_once(KERN_ERR "kvm: disabled by bios\n");
r = -EOPNOTSUPP;
goto out;
}
--
2.24.1
^ permalink raw reply related
* Re: [RFC PATCH v2 4/9] vfio-ccw: Introduce a new schib region
From: Eric Farman @ 2020-02-14 14:29 UTC (permalink / raw)
To: Cornelia Huck; +Cc: Halil Pasic, Jason Herne, Jared Rossi, linux-s390, kvm
In-Reply-To: <20200214133218.6841b81e.cohuck@redhat.com>
On 2/14/20 7:32 AM, Cornelia Huck wrote:
> On Thu, 6 Feb 2020 22:38:20 +0100
> Eric Farman <farman@linux.ibm.com> wrote:
>
>> From: Farhan Ali <alifm@linux.ibm.com>
>>
>> The schib region can be used by userspace to get the subchannel-
>> information block (SCHIB) for the passthrough subchannel.
>> This can be useful to get information such as channel path
>> information via the SCHIB.PMCW fields.
>>
>> Signed-off-by: Farhan Ali <alifm@linux.ibm.com>
>> Signed-off-by: Eric Farman <farman@linux.ibm.com>
>> ---
>>
>> Notes:
>> v1->v2:
>> - Add new region info to Documentation/s390/vfio-ccw.rst [CH]
>> - Add a block comment to struct ccw_schib_region [CH]
>>
>> v0->v1: [EF]
>> - Clean up checkpatch (#include, whitespace) errors
>> - Remove unnecessary includes from vfio_ccw_chp.c
>> - Add ret=-ENOMEM in error path for new region
>> - Add call to vfio_ccw_unregister_dev_regions() during error exit
>> path of vfio_ccw_mdev_open()
>> - New info on the module prologue
>> - Reorder cleanup of regions
>>
>> Documentation/s390/vfio-ccw.rst | 16 +++++-
>> drivers/s390/cio/Makefile | 2 +-
>> drivers/s390/cio/vfio_ccw_chp.c | 75 +++++++++++++++++++++++++++++
>> drivers/s390/cio/vfio_ccw_drv.c | 20 ++++++++
>> drivers/s390/cio/vfio_ccw_ops.c | 14 +++++-
>> drivers/s390/cio/vfio_ccw_private.h | 3 ++
>> include/uapi/linux/vfio.h | 1 +
>> include/uapi/linux/vfio_ccw.h | 10 ++++
>> 8 files changed, 137 insertions(+), 4 deletions(-)
>> create mode 100644 drivers/s390/cio/vfio_ccw_chp.c
>>
>> diff --git a/Documentation/s390/vfio-ccw.rst b/Documentation/s390/vfio-ccw.rst
>> index fca9c4f5bd9c..b805dc995fc8 100644
>> --- a/Documentation/s390/vfio-ccw.rst
>> +++ b/Documentation/s390/vfio-ccw.rst
>> @@ -231,6 +231,19 @@ This region is exposed via region type VFIO_REGION_SUBTYPE_CCW_ASYNC_CMD.
>>
>> Currently, CLEAR SUBCHANNEL and HALT SUBCHANNEL use this region.
>>
>> +vfio-ccw schib region
>> +---------------------
>> +
>> +The vfio-ccw schib region is used to return Subchannel-Information
>> +Block (SCHIB) data to userspace::
>> +
>> + struct ccw_schib_region {
>> + #define SCHIB_AREA_SIZE 52
>> + __u8 schib_area[SCHIB_AREA_SIZE];
>> + } __packed;
>> +
>> +This region is exposed via region type VFIO_REGION_SUBTYPE_CCW_SCHIB.
>
> Also mention that reading this triggers a stsch() updating the schib?
Yeah, I tucked that in the uapi header, but it should be mentioned here too.
>
>> +
>> vfio-ccw operation details
>> --------------------------
>>
>
> (...)
>
>> diff --git a/drivers/s390/cio/vfio_ccw_chp.c b/drivers/s390/cio/vfio_ccw_chp.c
>> new file mode 100644
>> index 000000000000..826d08379fe3
>> --- /dev/null
>> +++ b/drivers/s390/cio/vfio_ccw_chp.c
>> @@ -0,0 +1,75 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Channel path related status regions for vfio_ccw
>> + *
>> + * Copyright IBM Corp. 2019
>
> Should the year be updated?
Probably. :)
>
>> + *
>> + * Author(s): Farhan Ali <alifm@linux.ibm.com>
>> + */
>
> (...)
>
^ permalink raw reply
* Re: [RFC PATCH v2 9/9] vfio-ccw: Remove inline get_schid() routine
From: Eric Farman @ 2020-02-14 14:27 UTC (permalink / raw)
To: Cornelia Huck; +Cc: Halil Pasic, Jason Herne, Jared Rossi, linux-s390, kvm
In-Reply-To: <20200214142706.4d6a1efc.cohuck@redhat.com>
On 2/14/20 8:27 AM, Cornelia Huck wrote:
> On Thu, 6 Feb 2020 22:38:25 +0100
> Eric Farman <farman@linux.ibm.com> wrote:
>
>> This seems misplaced in the middle of FSM, returning the schid
>> field from inside the private struct. We could move this macro
>> into vfio_ccw_private.h, but this doesn't seem to simplify things
>> that much. Let's just remove it, and use the field directly.
>
> It had been introduced with the first set of traces, I'm now wondering
> why, as it doesn't do any checking.
Hrm, that's a decent question. I could refactor this, moving the
routine into vfio_ccw_private.h and add those checks, rather than
removing it outright.
I honestly only stumbled on this when I tried to use get_schid()
somewhere else, not realizing the definition was actually tucked away in
here. And so I've left it on the end of this series as a matter of
convenience/non-forgetfulness, but splitting it out by itself would be fine.
>
>>
>> Signed-off-by: Eric Farman <farman@linux.ibm.com>
>> ---
>> drivers/s390/cio/vfio_ccw_fsm.c | 8 ++------
>> 1 file changed, 2 insertions(+), 6 deletions(-)
>
^ permalink raw reply
* Re: [PATCH V2 3/5] vDPA: introduce vDPA bus
From: Jason Gunthorpe @ 2020-02-14 14:04 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, linux-kernel, kvm, virtualization, netdev,
tiwei.bie, maxime.coquelin, cunming.liang, zhihong.wang,
rob.miller, xiao.w.wang, haotian.wang, lingshan.zhu, eperezma,
lulu, parav, kevin.tian, stefanha, rdunlap, hch, aadam, jiri,
shahafs, hanand, mhabets
In-Reply-To: <5625f971-0455-6463-2c0a-cbca6a1f8271@redhat.com>
On Fri, Feb 14, 2020 at 12:05:32PM +0800, Jason Wang wrote:
> > The standard driver model is a 'bus' driver provides the HW access
> > (think PCI level things), and a 'hw driver' attaches to the bus
> > device,
>
> This is not true, kernel had already had plenty virtual bus where virtual
> devices and drivers could be attached, besides mdev and virtio, you can see
> vop, rpmsg, visorbus etc.
Sure, but those are not connecting HW into the kernel..
> > and instantiates a 'subsystem device' (think netdev, rdma,
> > etc) using some per-subsystem XXX_register().
>
>
> Well, if you go through virtio spec, we support ~20 types of different
> devices. Classes like netdev and rdma are correct since they have a clear
> set of semantics their own. But grouping network and scsi into a single
> class looks wrong, that's the work of a virtual bus.
rdma also has about 20 different types of things it supports on top of
the generic ib_device.
The central point in RDMA is the 'struct ib_device' which is a device
class. You can discover all RDMA devices by looking in /sys/class/infiniband/
It has an internal bus like thing (which probably should have been an
actual bus, but this was done 15 years ago) which allows other
subsystems to have drivers to match and bind their own drivers to the
struct ib_device.
So you'd have a chain like:
struct pci_device -> struct ib_device -> [ib client bus thing] -> struct net_device
And the various char devs are created by clients connecting to the
ib_device and creating char devs on their own classes.
Since ib_devices are multi-queue we can have all 20 devices running
concurrently and there are various schemes to manage when the various
things are created.
> > The 'hw driver' pulls in
> > functions from the 'subsystem' using a combination of callbacks and
> > library-style calls so there is no code duplication.
>
> The point is we want vDPA devices to be used by different subsystems, not
> only vhost, but also netdev, blk, crypto (every subsystem that can use
> virtio devices). That's why we introduce vDPA bus and introduce different
> drivers on top.
See the other mail, it seems struct virtio_device serves this purpose
already, confused why a struct vdpa_device and another bus is being
introduced
> There're several examples that a bus is needed on top.
>
> A good example is Mellanox TmFIFO driver which is a platform device driver
> but register itself as a virtio device in order to be used by virito-console
> driver on the virtio bus.
How is that another bus? The platform bus is the HW bus, the TmFIFO is
the HW driver, and virtio_device is the subsystem.
This seems reasonable/normal so far..
> But it's a pity that the device can not be used by userspace driver due to
> the limitation of virito bus which is designed for kernel driver. That's why
> vDPA bus is introduced which abstract the common requirements of both kernel
> and userspace drivers which allow the a single HW driver to be used by
> kernel drivers (and the subsystems on top) and userspace drivers.
Ah! Maybe this is the source of all this strangeness - the userspace
driver is something parallel to the struct virtio_device instead of
being a consumer of it?? That certianly would mess up the driver model
quite a lot.
Then you want to add another bus to switch between vhost and struct
virtio_device? But only for vdpa?
But as you point out something like TmFIFO is left hanging. Seems like
the wrong abstraction point..
Jason
^ permalink raw reply
* Re: [PATCH V2 3/5] vDPA: introduce vDPA bus
From: Jason Gunthorpe @ 2020-02-14 13:52 UTC (permalink / raw)
To: Jason Wang
Cc: mst, linux-kernel, kvm, virtualization, netdev, tiwei.bie,
maxime.coquelin, cunming.liang, zhihong.wang, rob.miller,
xiao.w.wang, haotian.wang, lingshan.zhu, eperezma, lulu, parav,
kevin.tian, stefanha, rdunlap, hch, aadam, jiri, shahafs, hanand,
mhabets
In-Reply-To: <8b3e6a9c-8bfd-fb3c-12a8-2d6a3879f1ae@redhat.com>
On Fri, Feb 14, 2020 at 11:23:27AM +0800, Jason Wang wrote:
> > > Though all vDPA devices have the same programming interface, but the
> > > semantic is different. So it looks to me that use bus complies what
> > > class.rst said:
> > >
> > > "
> > >
> > > Each device class defines a set of semantics and a programming interface
> > > that devices of that class adhere to. Device drivers are the
> > > implementation of that programming interface for a particular device on
> > > a particular bus.
> > >
> > > "
> > Here we are talking about the /dev/XX node that provides the
> > programming interface.
>
>
> I'm confused here, are you suggesting to use class to create char device in
> vhost-vdpa? That's fine but the comment should go for vhost-vdpa patch.
Certainly yes, something creating many char devs should have a
class. That makes the sysfs work as expected
I suppose this is vhost user? I admit I don't really see how this
vhost stuff works, all I see are global misc devices? Very unusual for
a new subsystem to be using global misc devices..
I would have expected that a single VDPA device comes out as a single
char dev linked to only that VDPA device.
> > All the vdpa devices have the same basic
> > chardev interface and discover any semantic variations 'in band'
>
> That's not true, char interface is only used for vhost. Kernel virtio driver
> does not need char dev but a device on the virtio bus.
Okay, this is fine, but why do you need two busses to accomplish this?
Shouldn't the 'struct virito_device' be the plug in point for HW
drivers I was talking about - and from there a vhost-user can connect
to the struct virtio_device to give it a char dev or a kernel driver
can connect to link it to another subsystem?
It is easy to see something is going wrong with this design because
the drivers/virtio/virtio_vdpa.c mainly contains a bunch of trampoline
functions reflecting identical calls from one ops struct to a
different ops struct. This suggests the 'vdpa' is some subclass of
'virtio' and it is possibly better to model it by extending 'struct
virito_device' to include the vdpa specific stuff.
Where does the vhost-user char dev get invovled in with the v2 series?
Is that included?
> > Every class of virtio traffic is going to need a special HW driver to
> > enable VDPA, that special driver can create the correct vhost side
> > class device.
>
> Are you saying, e.g it's the charge of IFCVF driver to create vhost char dev
> and other stuffs?
No.
Jason
^ permalink raw reply
* Re: [RFC PATCH v2 7/9] vfio-ccw: Wire up the CRW irq and CRW region
From: Cornelia Huck @ 2020-02-14 13:34 UTC (permalink / raw)
To: Eric Farman; +Cc: Halil Pasic, Jason Herne, Jared Rossi, linux-s390, kvm
In-Reply-To: <20200206213825.11444-8-farman@linux.ibm.com>
On Thu, 6 Feb 2020 22:38:23 +0100
Eric Farman <farman@linux.ibm.com> wrote:
> From: Farhan Ali <alifm@linux.ibm.com>
>
> Use an IRQ to notify userspace that there is a CRW
> pending in the region, related to path-availability
> changes on the passthrough subchannel.
>
> Signed-off-by: Farhan Ali <alifm@linux.ibm.com>
> Signed-off-by: Eric Farman <farman@linux.ibm.com>
> ---
>
> Notes:
> v1->v2:
> - Remove extraneous 0x0 in crw.rsid assignment [CH]
> - Refactor the building/queueing of a crw into its own routine [EF]
>
> v0->v1: [EF]
> - Place the non-refactoring changes from the previous patch here
> - Clean up checkpatch (whitespace) errors
> - s/chp_crw/crw/
> - Move acquire/release of io_mutex in vfio_ccw_crw_region_read()
> into patch that introduces that region
> - Remove duplicate include from vfio_ccw_drv.c
> - Reorder include in vfio_ccw_private.h
>
> drivers/s390/cio/vfio_ccw_chp.c | 5 ++
> drivers/s390/cio/vfio_ccw_drv.c | 73 +++++++++++++++++++++++++++++
> drivers/s390/cio/vfio_ccw_ops.c | 4 ++
> drivers/s390/cio/vfio_ccw_private.h | 9 ++++
> include/uapi/linux/vfio.h | 1 +
> 5 files changed, 92 insertions(+)
>
(...)
> +static void vfio_ccw_alloc_crw(struct vfio_ccw_private *private,
> + struct chp_link *link,
> + unsigned int erc)
> +{
> + struct vfio_ccw_crw *vc_crw;
> + struct crw *crw;
> +
> + /*
> + * If unable to allocate a CRW, just drop the event and
> + * carry on. The guest will either see a later one or
> + * learn when it issues its own store subchannel.
> + */
> + vc_crw = kzalloc(sizeof(*vc_crw), GFP_ATOMIC);
> + if (!vc_crw)
> + return;
> +
> + /*
> + * Build in the first CRW space, but don't chain anything
> + * into the second one even though the space exists.
> + */
> + crw = &vc_crw->crw[0];
> +
> + /*
> + * Presume every CRW we handle is reported by a channel-path.
> + * Maybe not future-proof, but good for what we're doing now.
You could pass in a source indication, maybe? Presumably, at least one
of the callers further up the chain knows...
> + *
> + * FIXME Sort of a lie, since we're converting a CRW
> + * reported by a channel-path into one issued to each
> + * subchannel, but still saying it's coming from the path.
It's still channel-path related, though :)
The important point is probably is that userspace needs to be aware
that the same channel-path related event is reported on all affected
subchannels, and they therefore need some appropriate handling on their
side.
> + */
> + crw->rsc = CRW_RSC_CPATH;
> + crw->rsid = (link->chpid.cssid << 8) | link->chpid.id;
> + crw->erc = erc;
> +
> + list_add_tail(&vc_crw->next, &private->crw);
> + queue_work(vfio_ccw_work_q, &private->crw_work);
> +}
> +
> static int vfio_ccw_chp_event(struct subchannel *sch,
> struct chp_link *link, int event)
> {
(...)
^ permalink raw reply
* Re: [RFC PATCH v2 9/9] vfio-ccw: Remove inline get_schid() routine
From: Cornelia Huck @ 2020-02-14 13:27 UTC (permalink / raw)
To: Eric Farman; +Cc: Halil Pasic, Jason Herne, Jared Rossi, linux-s390, kvm
In-Reply-To: <20200206213825.11444-10-farman@linux.ibm.com>
On Thu, 6 Feb 2020 22:38:25 +0100
Eric Farman <farman@linux.ibm.com> wrote:
> This seems misplaced in the middle of FSM, returning the schid
> field from inside the private struct. We could move this macro
> into vfio_ccw_private.h, but this doesn't seem to simplify things
> that much. Let's just remove it, and use the field directly.
It had been introduced with the first set of traces, I'm now wondering
why, as it doesn't do any checking.
>
> Signed-off-by: Eric Farman <farman@linux.ibm.com>
> ---
> drivers/s390/cio/vfio_ccw_fsm.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
^ permalink raw reply
* Re: [PATCH kvm-unit-tests 2/2] runtime: Introduce VMM_PARAMS
From: Paolo Bonzini @ 2020-02-14 13:10 UTC (permalink / raw)
To: Andrew Jones
Cc: kvm, peter.maydell, alex.bennee, lvivier, thuth, david, frankja,
eric.auger
In-Reply-To: <20200214115051.o4t6ro55y42oztxf@kamzik.brq.redhat.com>
On 14/02/20 12:50, Andrew Jones wrote:
> After
> -----
>
> $ ./run_tests.sh -j 2 -v pmu psci
> PASS psci (4 tests)
>
> $ ./run_tests.sh pmu psci -j 2 -v
> $
>
> (no output)
Bugs. :)
> $ ./run_tests.sh -j 2 -v -- pmu psci
> $
>
> (no output)
This is intended, it shouldn't be a big deal because we don't have tests
starting with a dash.
Paolo
^ permalink raw reply
* Re: vhost changes (batched) in linux-next after 12/13 trigger random crashes in KVM guests after reboot
From: Christian Borntraeger @ 2020-02-14 12:34 UTC (permalink / raw)
To: Eugenio Pérez
Cc: Michael S. Tsirkin, virtualization@lists.linux-foundation.org,
Stephen Rothwell, Linux Next Mailing List,
linux-kernel@vger.kernel.org, kvm list, Halil Pasic,
Cornelia Huck
In-Reply-To: <8e226821a8878f53585d967b8af547526d84c73e.camel@redhat.com>
On 14.02.20 13:26, Eugenio Pérez wrote:
> On Fri, 2020-02-14 at 13:22 +0100, Christian Borntraeger wrote:
>>
>> On 14.02.20 13:17, Eugenio Pérez wrote:
>>> Can you try the inlined patch over 52c36ce7f334 ("vhost: use batched version by default")? My intention is to check
>>> if
>>> "strange VHOST_SET_VRING_BASE" line appears. In previous tests, it appears very fast, but maybe it takes some time
>>> for
>>> it to appear, or it does not appear anymore.
yep it does:
[ 67.801012] [1917] vhost:vhost_vring_ioctl:1655: VHOST_SET_VRING_BASE [vq=0000000088199421][vq->last_avail_idx=0][vq->avail_idx=0][s.index=0][s.num=0]
[ 67.801018] [1917] vhost:vhost_vring_ioctl:1655: VHOST_SET_VRING_BASE [vq=00000000175f11ec][vq->last_avail_idx=0][vq->avail_idx=0][s.index=1][s.num=0]
[ 67.801026] [1917] vhost_net:vhost_net_ioctl:1726: VHOST_NET_SET_BACKEND
[ 67.801028] [1917] vhost_net:vhost_net_set_backend:1538: sock=0000000082d8d291 != oldsock=000000001ae027fd index=0 fd=39 vq=0000000088199421
[ 67.801032] [1917] vhost_net:vhost_net_set_backend:1573: sock=0000000082d8d291
[ 67.801033] [1917] vhost_net:vhost_net_ioctl:1726: VHOST_NET_SET_BACKEND
[ 67.801034] [1917] vhost_net:vhost_net_set_backend:1538: sock=0000000082d8d291 != oldsock=000000001ae027fd index=1 fd=39 vq=00000000175f11ec
[ 67.801035] [1917] vhost_net:vhost_net_set_backend:1573: sock=0000000082d8d291
[ 67.801037] [1915] vhost:vhost_discard_vq_desc:2424: DISCARD [vq=0000000088199421][vq->last_avail_idx=0][vq->avail_idx=0][n=0]
[ 68.648803] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=0][vq->avail_idx=256][vq->ndescs=1]
[ 68.648810] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=1][vq->avail_idx=256][vq->ndescs=1]
[ 68.648812] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=2][vq->avail_idx=256][vq->ndescs=1]
[ 68.648815] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=3][vq->avail_idx=256][vq->ndescs=1]
[ 68.648817] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=4][vq->avail_idx=256][vq->ndescs=1]
[ 68.648818] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=5][vq->avail_idx=256][vq->ndescs=1]
[ 68.648820] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=6][vq->avail_idx=256][vq->ndescs=1]
[ 68.648822] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=7][vq->avail_idx=256][vq->ndescs=1]
[ 68.648824] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=8][vq->avail_idx=256][vq->ndescs=1]
[ 68.648826] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=9][vq->avail_idx=256][vq->ndescs=1]
[ 68.648828] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=10][vq->avail_idx=256][vq->ndescs=1]
[ 68.648829] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=11][vq->avail_idx=256][vq->ndescs=1]
[ 68.648831] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=12][vq->avail_idx=256][vq->ndescs=1]
[ 68.648832] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=13][vq->avail_idx=256][vq->ndescs=1]
[ 68.648833] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=14][vq->avail_idx=256][vq->ndescs=1]
[ 68.670292] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=0][vq->avail_idx=1][vq->ndescs=1]
[ 68.687187] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=1][vq->avail_idx=2][vq->ndescs=1]
[ 68.687623] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=15][vq->avail_idx=256][vq->ndescs=1]
[ 68.687641] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=2][vq->avail_idx=4][vq->ndescs=1]
[ 68.687642] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=3][vq->avail_idx=4][vq->ndescs=1]
[ 68.690274] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=16][vq->avail_idx=256][vq->ndescs=1]
[ 68.690539] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=4][vq->avail_idx=5][vq->ndescs=1]
[ 68.715379] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=17][vq->avail_idx=256][vq->ndescs=1]
[ 68.800525] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=5][vq->avail_idx=6][vq->ndescs=1]
[ 68.890537] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=6][vq->avail_idx=7][vq->ndescs=1]
[ 68.900587] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=7][vq->avail_idx=8][vq->ndescs=1]
[ 68.916837] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=8][vq->avail_idx=9][vq->ndescs=2]
[ 68.928828] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=18][vq->avail_idx=256][vq->ndescs=1]
[ 69.090540] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=9][vq->avail_idx=10][vq->ndescs=1]
[ 69.119651] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=10][vq->avail_idx=11][vq->ndescs=2]
[ 69.132325] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=19][vq->avail_idx=256][vq->ndescs=1]
[ 69.323473] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=11][vq->avail_idx=12][vq->ndescs=2]
[ 69.354557] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=20][vq->avail_idx=256][vq->ndescs=1]
[ 69.442550] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=21][vq->avail_idx=256][vq->ndescs=1]
[ 69.523593] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=12][vq->avail_idx=13][vq->ndescs=2]
[ 69.557360] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=22][vq->avail_idx=256][vq->ndescs=1]
[ 69.980634] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=13][vq->avail_idx=14][vq->ndescs=1]
[ 69.981364] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=14][vq->avail_idx=15][vq->ndescs=1]
[ 70.010545] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=15][vq->avail_idx=16][vq->ndescs=1]
[ 70.161316] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=23][vq->avail_idx=256][vq->ndescs=1]
[ 70.177640] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=24][vq->avail_idx=256][vq->ndescs=1]
[ 70.280564] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=16][vq->avail_idx=17][vq->ndescs=1]
[ 70.670327] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=17][vq->avail_idx=18][vq->ndescs=1]
[ 70.932887] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=18][vq->avail_idx=19][vq->ndescs=2]
[ 70.940587] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=19][vq->avail_idx=20][vq->ndescs=1]
[ 70.947598] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=25][vq->avail_idx=256][vq->ndescs=1]
[ 71.070388] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=20][vq->avail_idx=21][vq->ndescs=1]
[ 71.070770] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=26][vq->avail_idx=256][vq->ndescs=1]
[ 71.070805] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=21][vq->avail_idx=22][vq->ndescs=1]
[ 71.070977] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=27][vq->avail_idx=256][vq->ndescs=1]
[ 71.071049] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=22][vq->avail_idx=23][vq->ndescs=1]
[ 71.071195] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=28][vq->avail_idx=256][vq->ndescs=1]
[ 71.071243] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=23][vq->avail_idx=24][vq->ndescs=1]
[ 71.071386] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=29][vq->avail_idx=256][vq->ndescs=1]
[ 71.071433] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=24][vq->avail_idx=25][vq->ndescs=1]
[ 71.071575] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=30][vq->avail_idx=256][vq->ndescs=1]
[ 71.071611] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=25][vq->avail_idx=26][vq->ndescs=1]
[ 71.071747] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=31][vq->avail_idx=256][vq->ndescs=1]
[ 71.071789] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=26][vq->avail_idx=27][vq->ndescs=1]
[ 71.071923] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=32][vq->avail_idx=256][vq->ndescs=1]
[ 71.071960] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=27][vq->avail_idx=28][vq->ndescs=1]
[ 71.072096] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=33][vq->avail_idx=256][vq->ndescs=1]
[ 71.072128] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=28][vq->avail_idx=29][vq->ndescs=1]
[ 71.072267] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=34][vq->avail_idx=256][vq->ndescs=1]
[ 71.072300] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=29][vq->avail_idx=30][vq->ndescs=1]
[ 71.072432] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=35][vq->avail_idx=256][vq->ndescs=1]
[ 71.072463] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=30][vq->avail_idx=31][vq->ndescs=1]
[ 71.072596] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=36][vq->avail_idx=256][vq->ndescs=1]
[ 71.072630] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=31][vq->avail_idx=32][vq->ndescs=1]
[ 71.072759] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=37][vq->avail_idx=256][vq->ndescs=1]
[ 71.072791] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=32][vq->avail_idx=33][vq->ndescs=1]
[ 71.072933] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=38][vq->avail_idx=256][vq->ndescs=1]
[ 71.073054] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=33][vq->avail_idx=34][vq->ndescs=1]
[ 71.073193] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=39][vq->avail_idx=256][vq->ndescs=1]
[ 71.073247] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=34][vq->avail_idx=35][vq->ndescs=1]
[ 71.073383] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=40][vq->avail_idx=256][vq->ndescs=1]
[ 71.073434] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=35][vq->avail_idx=36][vq->ndescs=1]
[ 71.073571] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=41][vq->avail_idx=256][vq->ndescs=1]
[ 71.073627] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=36][vq->avail_idx=37][vq->ndescs=1]
[ 71.073762] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=42][vq->avail_idx=256][vq->ndescs=1]
[ 71.073813] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=37][vq->avail_idx=38][vq->ndescs=1]
[ 71.073948] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=43][vq->avail_idx=256][vq->ndescs=1]
[ 71.073998] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=38][vq->avail_idx=39][vq->ndescs=1]
[ 71.074136] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=44][vq->avail_idx=256][vq->ndescs=1]
[ 71.074186] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=39][vq->avail_idx=40][vq->ndescs=1]
[ 71.074320] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=45][vq->avail_idx=256][vq->ndescs=1]
[ 71.074370] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=40][vq->avail_idx=41][vq->ndescs=1]
[ 71.074503] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=46][vq->avail_idx=256][vq->ndescs=1]
[ 72.344493] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=47][vq->avail_idx=256][vq->ndescs=1]
[ 72.553413] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=48][vq->avail_idx=256][vq->ndescs=1]
[ 73.522174] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=49][vq->avail_idx=256][vq->ndescs=1]
[ 73.705202] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=50][vq->avail_idx=256][vq->ndescs=1]
[ 73.705239] [1915] vhost:fetch_descs:2328: [vq=00000000175f11ec][vq->last_avail_idx=41][vq->avail_idx=42][vq->ndescs=1]
[ 73.994388] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=51][vq->avail_idx=256][vq->ndescs=1]
[ 74.208443] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=52][vq->avail_idx=256][vq->ndescs=1]
[ 74.433345] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=53][vq->avail_idx=256][vq->ndescs=1]
[ 74.594756] [1910] vhost_net:vhost_net_ioctl:1726: VHOST_NET_SET_BACKEND
[ 74.594761] [1910] vhost_net:vhost_net_set_backend:1538: sock=000000001ae027fd != oldsock=0000000082d8d291 index=0 fd=-1 vq=0000000088199421
[ 74.594762] [1910] vhost_net:vhost_net_set_backend:1573: sock=000000001ae027fd
[ 74.594803] [1910] vhost_net:vhost_net_ioctl:1726: VHOST_NET_SET_BACKEND
[ 74.594804] [1910] vhost_net:vhost_net_set_backend:1538: sock=000000001ae027fd != oldsock=0000000082d8d291 index=1 fd=-1 vq=00000000175f11ec
[ 74.594805] [1910] vhost_net:vhost_net_set_backend:1573: sock=000000001ae027fd
[ 74.594847] [1910] vhost:vhost_vring_ioctl:1664: VHOST_GET_VRING_BASE [vq=0000000088199421][vq->last_avail_idx=54][vq->avail_idx=256][s.index=0][s.num=54]
[ 74.594850] [1910] vhost:vhost_vring_ioctl:1664: VHOST_GET_VRING_BASE [vq=00000000175f11ec][vq->last_avail_idx=42][vq->avail_idx=42][s.index=1][s.num=42]
[ 77.003191] [1918] vhost:vhost_vring_ioctl:1645: strange VHOST_SET_VRING_BASE [vq=0000000088199421][s.index=0][s.num=0]
[ 77.003194] CPU: 62 PID: 1918 Comm: CPU 1/KVM Not tainted 5.5.0+ #22
[ 77.003197] Hardware name: IBM 3906 M04 704 (LPAR)
[ 77.003198] Call Trace:
[ 77.003207] [<0000000b8d93c132>] show_stack+0x8a/0xd0
[ 77.003211] [<0000000b8e32e72a>] dump_stack+0x8a/0xb8
[ 77.003224] [<000003ff803567ae>] vhost_vring_ioctl+0x6fe/0x858 [vhost]
[ 77.003228] [<000003ff8036c670>] vhost_net_ioctl+0x510/0x570 [vhost_net]
[ 77.003234] [<0000000b8dbecdd8>] do_vfs_ioctl+0x430/0x6f8
[ 77.003235] [<0000000b8dbed124>] ksys_ioctl+0x84/0xb0
[ 77.003237] [<0000000b8dbed1ba>] __s390x_sys_ioctl+0x2a/0x38
[ 77.003240] [<0000000b8e34ff72>] system_call+0x2a6/0x2c8
[ 77.003261] [1918] vhost:vhost_vring_ioctl:1645: strange VHOST_SET_VRING_BASE [vq=00000000175f11ec][s.index=1][s.num=0]
[ 77.003262] CPU: 62 PID: 1918 Comm: CPU 1/KVM Not tainted 5.5.0+ #22
[ 77.003263] Hardware name: IBM 3906 M04 704 (LPAR)
[ 77.003264] Call Trace:
[ 77.003266] [<0000000b8d93c132>] show_stack+0x8a/0xd0
[ 77.003267] [<0000000b8e32e72a>] dump_stack+0x8a/0xb8
[ 77.003270] [<000003ff803567ae>] vhost_vring_ioctl+0x6fe/0x858 [vhost]
[ 77.003271] [<000003ff8036c670>] vhost_net_ioctl+0x510/0x570 [vhost_net]
[ 77.003273] [<0000000b8dbecdd8>] do_vfs_ioctl+0x430/0x6f8
[ 77.003274] [<0000000b8dbed124>] ksys_ioctl+0x84/0xb0
[ 77.003276] [<0000000b8dbed1ba>] __s390x_sys_ioctl+0x2a/0x38
[ 77.003277] [<0000000b8e34ff72>] system_call+0x2a6/0x2c8
[ 77.003297] [1918] vhost_net:vhost_net_ioctl:1726: VHOST_NET_SET_BACKEND
[ 77.003300] [1918] vhost_net:vhost_net_set_backend:1538: sock=0000000082d8d291 != oldsock=000000001ae027fd index=0 fd=39 vq=0000000088199421
[ 77.003304] [1918] vhost_net:vhost_net_set_backend:1573: sock=0000000082d8d291
[ 77.003305] [1918] vhost_net:vhost_net_ioctl:1726: VHOST_NET_SET_BACKEND
[ 77.003306] [1918] vhost_net:vhost_net_set_backend:1538: sock=0000000082d8d291 != oldsock=000000001ae027fd index=1 fd=39 vq=00000000175f11ec
[ 77.003308] [1915] vhost:fetch_descs:2328: [vq=0000000088199421][vq->last_avail_idx=54][vq->avail_idx=256][vq->ndescs=1]
[ 77.003308] [1918] vhost_net:vhost_net_set_backend:1573: sock=0000000082d8d291
[ 77.003310] [1915] vhost_net:get_rx_bufs:1061: unexpected descriptor format for RX: out 0, in 0
[ 77.003312] [1915] vhost:vhost_discard_vq_desc:2424: DISCARD [vq=0000000088199421][vq->last_avail_idx=55][vq->avail_idx=256][n=0]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox