There's a general issue with both PIO and MMIO reads (as detailed in
the comment); do a work-around for now.
Signed-off-by: George Dunlap <george.dun...@cloud.com>
---
tools/xentrace/xenalyze.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index 19b99dc66d..eb0e60e6ef 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -4650,6 +4650,24 @@ void hvm_generic_postprocess(struct hvm_data *h)
case VMEXIT_EXCEPTION_AC:
case VMEXIT_EXCEPTION_UD:
return;
+ case VMEXIT_IOIO:
+ /*
+ * FIXME: Both IO and MMIO reads which have gone out
+ * to the emulator and back typically have the
+ * [mm]io_assist trace happen on resume, just before
+ * the subsequent VMENTRY.
+ *
+ * However, when a VM has blocked, we call
+ * hvm_vmexit_close() when it becomes RUNNABLE again,
+ * rather than when it actually runs again; meaning
+ * that when hvm_vmexit_close() is called, no HVM
+ * handler has been seen.
+ *
+ * What we really need is some sort of intermediate
+ * state for [mm]io reads; but for now just ignore
+ * VMEXIT_IOIO exits without a handler.
+ */
+ return;
default:
break;
}
--
2.25.1
