From: Fabiano Rosas <farosas@linux.ibm.com>
To: qemu-devel@nongnu.org
Cc: qemu-ppc@nongnu.org, philmd@redhat.com, pbonzini@redhat.com,
crosthwaite.peter@gmail.com, rth@twiddle.net,
david@gibson.dropbear.id.au, cohuck@redhat.com, aik@ozlabs.ru
Subject: [Qemu-devel] [RFC PATCH v3 6/7] target/ppc: Refactor kvm_handle_debug
Date: Fri, 18 Jan 2019 12:07:57 -0200 [thread overview]
Message-ID: <20190118140758.829-7-farosas@linux.ibm.com> (raw)
In-Reply-To: <20190118140758.829-1-farosas@linux.ibm.com>
There are four scenarios being handled in this function:
- single stepping
- hardware breakpoints
- software breakpoints
- fallback (no debug supported)
A future patch will add code to handle specific single step and
software breakpoints cases so let's split each scenario into its own
function now to avoid hurting readability.
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
---
target/ppc/kvm.c | 86 ++++++++++++++++++++++++++++--------------------
1 file changed, 50 insertions(+), 36 deletions(-)
diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index 96a5895792..c27190d7fb 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -1621,52 +1621,66 @@ static int kvm_handle_hw_breakpoint(CPUState *cs,
return handle;
}
+static int kvm_handle_singlestep(void)
+{
+ return 1;
+}
+
+static int kvm_handle_sw_breakpoint(void)
+{
+ return 1;
+}
+
static int kvm_handle_debug(PowerPCCPU *cpu, struct kvm_run *run)
{
CPUState *cs = CPU(cpu);
CPUPPCState *env = &cpu->env;
struct kvm_debug_exit_arch *arch_info = &run->debug.arch;
- int handle = 0;
if (cs->singlestep_enabled) {
- handle = 1;
- } else if (arch_info->status) {
- handle = kvm_handle_hw_breakpoint(cs, arch_info);
- } else if (kvm_find_sw_breakpoint(cs, arch_info->address)) {
- handle = 1;
- } else {
- /* QEMU is not able to handle debug exception, so inject
- * program exception to guest;
- * Yes program exception NOT debug exception !!
- * When QEMU is using debug resources then debug exception must
- * be always set. To achieve this we set MSR_DE and also set
- * MSRP_DEP so guest cannot change MSR_DE.
- * When emulating debug resource for guest we want guest
- * to control MSR_DE (enable/disable debug interrupt on need).
- * Supporting both configurations are NOT possible.
- * So the result is that we cannot share debug resources
- * between QEMU and Guest on BOOKE architecture.
- * In the current design QEMU gets the priority over guest,
- * this means that if QEMU is using debug resources then guest
- * cannot use them;
- * For software breakpoint QEMU uses a privileged instruction;
- * So there cannot be any reason that we are here for guest
- * set debug exception, only possibility is guest executed a
- * privileged / illegal instruction and that's why we are
- * injecting a program interrupt.
- */
+ return kvm_handle_singlestep();
+ }
+
+ if (arch_info->status) {
+ return kvm_handle_hw_breakpoint(cs, arch_info);
+ }
- cpu_synchronize_state(cs);
- /* env->nip is PC, so increment this by 4 to use
- * ppc_cpu_do_interrupt(), which set srr0 = env->nip - 4.
- */
- env->nip += 4;
- cs->exception_index = POWERPC_EXCP_PROGRAM;
- env->error_code = POWERPC_EXCP_INVAL;
- ppc_cpu_do_interrupt(cs);
+ if (kvm_find_sw_breakpoint(cs, arch_info->address)) {
+ return kvm_handle_sw_breakpoint();
}
- return handle;
+ /*
+ * QEMU is not able to handle debug exception, so inject
+ * program exception to guest;
+ * Yes program exception NOT debug exception !!
+ * When QEMU is using debug resources then debug exception must
+ * be always set. To achieve this we set MSR_DE and also set
+ * MSRP_DEP so guest cannot change MSR_DE.
+ * When emulating debug resource for guest we want guest
+ * to control MSR_DE (enable/disable debug interrupt on need).
+ * Supporting both configurations are NOT possible.
+ * So the result is that we cannot share debug resources
+ * between QEMU and Guest on BOOKE architecture.
+ * In the current design QEMU gets the priority over guest,
+ * this means that if QEMU is using debug resources then guest
+ * cannot use them;
+ * For software breakpoint QEMU uses a privileged instruction;
+ * So there cannot be any reason that we are here for guest
+ * set debug exception, only possibility is guest executed a
+ * privileged / illegal instruction and that's why we are
+ * injecting a program interrupt.
+ */
+ cpu_synchronize_state(cs);
+ /*
+ * env->nip is PC, so increment this by 4 to use
+ * ppc_cpu_do_interrupt(), which set srr0 = env->nip - 4.
+ */
+ env->nip += 4;
+ cs->exception_index = POWERPC_EXCP_PROGRAM;
+ env->error_code = POWERPC_EXCP_INVAL;
+ ppc_cpu_do_interrupt(cs);
+
+ return 0;
}
int kvm_arch_handle_exit(CPUState *cs, struct kvm_run *run)
--
2.17.1
next prev parent reply other threads:[~2019-01-18 14:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-18 14:07 [Qemu-devel] [RFC PATCH v3 0/7] target/ppc: single step for KVM HV Fabiano Rosas
2019-01-18 14:07 ` [Qemu-devel] [RFC PATCH v3 1/7] target/ppc: Move exception vector offset computation into a function Fabiano Rosas
2019-01-25 1:22 ` Alexey Kardashevskiy
2019-01-18 14:07 ` [Qemu-devel] [RFC PATCH v3 2/7] target/ppc: Add ppc_get_trace_int_handler_addr Fabiano Rosas
2019-01-25 1:22 ` Alexey Kardashevskiy
2019-02-01 4:08 ` Alexey Kardashevskiy
2019-01-18 14:07 ` [Qemu-devel] [RFC PATCH v3 3/7] kvm: support checking for single step capability Fabiano Rosas
2019-01-25 1:24 ` Alexey Kardashevskiy
2019-01-18 14:07 ` [Qemu-devel] [RFC PATCH v3 4/7] kvm-all: Introduce kvm_set_singlestep Fabiano Rosas
2019-01-18 14:07 ` [Qemu-devel] [RFC PATCH v3 5/7] target/ppc: Move handling of hardware breakpoints to a separate function Fabiano Rosas
2019-01-18 14:07 ` Fabiano Rosas [this message]
2019-01-25 1:37 ` [Qemu-devel] [RFC PATCH v3 6/7] target/ppc: Refactor kvm_handle_debug Alexey Kardashevskiy
2019-01-18 14:07 ` [Qemu-devel] [RFC PATCH v3 7/7] target/ppc: support single stepping with KVM HV Fabiano Rosas
2019-01-25 4:52 ` Alexey Kardashevskiy
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=20190118140758.829-7-farosas@linux.ibm.com \
--to=farosas@linux.ibm.com \
--cc=aik@ozlabs.ru \
--cc=cohuck@redhat.com \
--cc=crosthwaite.peter@gmail.com \
--cc=david@gibson.dropbear.id.au \
--cc=pbonzini@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=rth@twiddle.net \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).