From: Ricardo Koller <ricarkol@google.com> To: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu Cc: pbonzini@redhat.com, maz@kernel.org, drjones@redhat.com, alexandru.elisei@arm.com, eric.auger@redhat.com, Ricardo Koller <ricarkol@google.com> Subject: [PATCH 3/3] KVM: selftests: Use a ucall for x86 unhandled vector reporting Date: Thu, 22 Apr 2021 21:03:51 -0700 [thread overview] Message-ID: <20210423040351.1132218-4-ricarkol@google.com> (raw) In-Reply-To: <20210423040351.1132218-1-ricarkol@google.com> x86 reports unhandled vectors using port IO at a specific port number, which is replicating what ucall already does for x86. Aarch64, on the other hand, reports unhandled vector exceptions with a ucall using a recently added UCALL_UNHANDLED ucall type. Replace the x86 unhandled vector exception handling to use ucall UCALL_UNHANDLED instead of port IO. Tested: Forcing a page fault in the ./x86_64/xapic_ipi_test halter_guest_code() shows this: $ ./x86_64/xapic_ipi_test ... Unexpected vectored event in guest (vector:0xe) Signed-off-by: Ricardo Koller <ricarkol@google.com> --- .../selftests/kvm/include/x86_64/processor.h | 2 -- .../testing/selftests/kvm/lib/x86_64/processor.c | 15 ++++++--------- 2 files changed, 6 insertions(+), 11 deletions(-) diff --git a/tools/testing/selftests/kvm/include/x86_64/processor.h b/tools/testing/selftests/kvm/include/x86_64/processor.h index 0b30b4e15c38..379f12cbdc06 100644 --- a/tools/testing/selftests/kvm/include/x86_64/processor.h +++ b/tools/testing/selftests/kvm/include/x86_64/processor.h @@ -53,8 +53,6 @@ #define CPUID_PKU (1ul << 3) #define CPUID_LA57 (1ul << 16) -#define UNEXPECTED_VECTOR_PORT 0xfff0u - /* General Registers in 64-Bit Mode */ struct gpr64_regs { u64 rax; diff --git a/tools/testing/selftests/kvm/lib/x86_64/processor.c b/tools/testing/selftests/kvm/lib/x86_64/processor.c index a8906e60a108..284d26a25cd3 100644 --- a/tools/testing/selftests/kvm/lib/x86_64/processor.c +++ b/tools/testing/selftests/kvm/lib/x86_64/processor.c @@ -1207,7 +1207,7 @@ static void set_idt_entry(struct kvm_vm *vm, int vector, unsigned long addr, void kvm_exit_unexpected_vector(uint32_t value) { - outl(UNEXPECTED_VECTOR_PORT, value); + ucall(UCALL_UNHANDLED, 1, value); } void route_exception(struct ex_regs *regs) @@ -1260,16 +1260,13 @@ void vm_handle_exception(struct kvm_vm *vm, int vector, void assert_on_unhandled_exception(struct kvm_vm *vm, uint32_t vcpuid) { - if (vcpu_state(vm, vcpuid)->exit_reason == KVM_EXIT_IO - && vcpu_state(vm, vcpuid)->io.port == UNEXPECTED_VECTOR_PORT - && vcpu_state(vm, vcpuid)->io.size == 4) { - /* Grab pointer to io data */ - uint32_t *data = (void *)vcpu_state(vm, vcpuid) - + vcpu_state(vm, vcpuid)->io.data_offset; + struct ucall uc; + if (get_ucall(vm, vcpuid, &uc) == UCALL_UNHANDLED) { + uint64_t vector = uc.args[0]; TEST_ASSERT(false, - "Unexpected vectored event in guest (vector:0x%x)", - *data); + "Unexpected vectored event in guest (vector:0x%lx)", + vector); } } -- 2.31.1.498.g6c1eba8ee3d-goog
WARNING: multiple messages have this Message-ID (diff)
From: Ricardo Koller <ricarkol@google.com> To: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu Cc: maz@kernel.org, pbonzini@redhat.com Subject: [PATCH 3/3] KVM: selftests: Use a ucall for x86 unhandled vector reporting Date: Thu, 22 Apr 2021 21:03:51 -0700 [thread overview] Message-ID: <20210423040351.1132218-4-ricarkol@google.com> (raw) In-Reply-To: <20210423040351.1132218-1-ricarkol@google.com> x86 reports unhandled vectors using port IO at a specific port number, which is replicating what ucall already does for x86. Aarch64, on the other hand, reports unhandled vector exceptions with a ucall using a recently added UCALL_UNHANDLED ucall type. Replace the x86 unhandled vector exception handling to use ucall UCALL_UNHANDLED instead of port IO. Tested: Forcing a page fault in the ./x86_64/xapic_ipi_test halter_guest_code() shows this: $ ./x86_64/xapic_ipi_test ... Unexpected vectored event in guest (vector:0xe) Signed-off-by: Ricardo Koller <ricarkol@google.com> --- .../selftests/kvm/include/x86_64/processor.h | 2 -- .../testing/selftests/kvm/lib/x86_64/processor.c | 15 ++++++--------- 2 files changed, 6 insertions(+), 11 deletions(-) diff --git a/tools/testing/selftests/kvm/include/x86_64/processor.h b/tools/testing/selftests/kvm/include/x86_64/processor.h index 0b30b4e15c38..379f12cbdc06 100644 --- a/tools/testing/selftests/kvm/include/x86_64/processor.h +++ b/tools/testing/selftests/kvm/include/x86_64/processor.h @@ -53,8 +53,6 @@ #define CPUID_PKU (1ul << 3) #define CPUID_LA57 (1ul << 16) -#define UNEXPECTED_VECTOR_PORT 0xfff0u - /* General Registers in 64-Bit Mode */ struct gpr64_regs { u64 rax; diff --git a/tools/testing/selftests/kvm/lib/x86_64/processor.c b/tools/testing/selftests/kvm/lib/x86_64/processor.c index a8906e60a108..284d26a25cd3 100644 --- a/tools/testing/selftests/kvm/lib/x86_64/processor.c +++ b/tools/testing/selftests/kvm/lib/x86_64/processor.c @@ -1207,7 +1207,7 @@ static void set_idt_entry(struct kvm_vm *vm, int vector, unsigned long addr, void kvm_exit_unexpected_vector(uint32_t value) { - outl(UNEXPECTED_VECTOR_PORT, value); + ucall(UCALL_UNHANDLED, 1, value); } void route_exception(struct ex_regs *regs) @@ -1260,16 +1260,13 @@ void vm_handle_exception(struct kvm_vm *vm, int vector, void assert_on_unhandled_exception(struct kvm_vm *vm, uint32_t vcpuid) { - if (vcpu_state(vm, vcpuid)->exit_reason == KVM_EXIT_IO - && vcpu_state(vm, vcpuid)->io.port == UNEXPECTED_VECTOR_PORT - && vcpu_state(vm, vcpuid)->io.size == 4) { - /* Grab pointer to io data */ - uint32_t *data = (void *)vcpu_state(vm, vcpuid) - + vcpu_state(vm, vcpuid)->io.data_offset; + struct ucall uc; + if (get_ucall(vm, vcpuid, &uc) == UCALL_UNHANDLED) { + uint64_t vector = uc.args[0]; TEST_ASSERT(false, - "Unexpected vectored event in guest (vector:0x%x)", - *data); + "Unexpected vectored event in guest (vector:0x%lx)", + vector); } } -- 2.31.1.498.g6c1eba8ee3d-goog _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
next prev parent reply other threads:[~2021-04-23 4:04 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-23 4:03 [PATCH 0/3] KVM: selftests: arm64 exception handling and debug test Ricardo Koller 2021-04-23 4:03 ` Ricardo Koller 2021-04-23 4:03 ` [PATCH 1/3] KVM: selftests: Add exception handling support for aarch64 Ricardo Koller 2021-04-23 4:03 ` Ricardo Koller 2021-04-23 8:58 ` Marc Zyngier 2021-04-23 8:58 ` Marc Zyngier 2021-04-23 11:05 ` Andrew Jones 2021-04-23 11:05 ` Andrew Jones 2021-04-26 18:58 ` Ricardo Koller 2021-04-26 18:58 ` Ricardo Koller 2021-04-29 17:51 ` Ricardo Koller 2021-04-29 17:51 ` Ricardo Koller 2021-04-29 19:59 ` Marc Zyngier 2021-04-29 19:59 ` Marc Zyngier 2021-04-29 20:48 ` Ricardo Koller 2021-04-29 20:48 ` Ricardo Koller 2021-04-23 4:03 ` [PATCH 2/3] KVM: selftests: Add aarch64/debug-exceptions test Ricardo Koller 2021-04-23 4:03 ` Ricardo Koller 2021-04-23 11:22 ` Andrew Jones 2021-04-23 11:22 ` Andrew Jones 2021-04-23 4:03 ` Ricardo Koller [this message] 2021-04-23 4:03 ` [PATCH 3/3] KVM: selftests: Use a ucall for x86 unhandled vector reporting Ricardo Koller 2021-04-23 10:45 ` Andrew Jones 2021-04-23 10:45 ` Andrew Jones
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210423040351.1132218-4-ricarkol@google.com \ --to=ricarkol@google.com \ --cc=alexandru.elisei@arm.com \ --cc=drjones@redhat.com \ --cc=eric.auger@redhat.com \ --cc=kvm@vger.kernel.org \ --cc=kvmarm@lists.cs.columbia.edu \ --cc=maz@kernel.org \ --cc=pbonzini@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.