qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH v3 01/11] plugins: add types for callbacks related to cer


From: Pierrick Bouvier
Subject: Re: [RFC PATCH v3 01/11] plugins: add types for callbacks related to certain discontinuities
Date: Wed, 4 Dec 2024 14:41:10 -0800
User-agent: Mozilla Thunderbird

On 12/3/24 00:45, Julian Ganz wrote:
Hi,

December 2, 2024 at 8:26 PM, "Julian Ganz" wrote:
diff --git a/include/qemu/qemu-plugin.h b/include/qemu/qemu-plugin.h
index 0fba36ae02..9c67374b7e 100644
--- a/include/qemu/qemu-plugin.h
+++ b/include/qemu/qemu-plugin.h
@@ -154,6 +154,49 @@ typedef void 
(*qemu_plugin_vcpu_simple_cb_t)(qemu_plugin_id_t id,
<snip>
+/**
+ * typedef qemu_plugin_vcpu_discon_cb_t - vcpu discontinuity callback
+ * @vcpu_index: the current vcpu context
+ * @type: the type of discontinuity
+ * @from_pc: the source of the discontinuity, e.g. the PC before the
+ * transition
+ * @to_pc: the PC pointing to the next instruction to be executed
+ *
+ * The excact semantics of @from_pc depends on @the type of discontinuity. For
+ * interrupts, @from_pc will point to the next instruction which would have
+ * been executed. For exceptions and host calls, @from_pc will point to the
+ * instruction that caused the exception or issued the host call. Note that
+ * in the case of exceptions, the instruction is not retired and thus not
+ * observable via general instruction exec callbacks. The same may be the case
+ * for some host calls such as hypervisor call "exceptions".

Some more notes about this bit: I originally tried to make the from_pc
semantics independent from the type of event, i.e. either of the two
cases. I obviously did not succeed in doing so. As, in most cases, the
instruction pointed to by from_pc is not observable via exec callbacks
I could also not test this behaviour in the testing plugin (see patch
11). I am therefore in favor for dropping the from_pc for the next
iteration of this patch series.


Does it mean that information returned should be dependent of type of event, as we previously discussed on v1?

+ */
+typedef void (*qemu_plugin_vcpu_discon_cb_t)(qemu_plugin_id_t id,
+ unsigned int vcpu_index,
+ enum qemu_plugin_discon_type type,
+ uint64_t from_pc, uint64_t to_pc);
+
  /**
  * qemu_plugin_uninstall() - Uninstall a plugin
  * @id: this plugin's opaque ID
--
2.45.2


Regards,
Julian





reply via email to

[Prev in Thread] Current Thread [Next in Thread]