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.dunlap@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