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

[PATCH WIP 05/14] xenalyze: Ignore vmexits where an HVM_HANDLER traces would be redundant



VMX combines all exceptions into a single VMEXIT exit reason, and so
needs a separate HVM_HANDLER trace record (HVM_TRAP) to say which
exception happened; but for a number of exceptions, no further
information is put into the trace log.

SVM, by contrast, has a separate VMEXIT exit reason for each exception
vector, so HVM_TRAP would be redundant.

NB that VMEXIT_EXCEPTION_DB doesn't have an HVM_HANDLER for SVM yet;
but for VMX, there's a specific HVM_HANDLER trace record which
includes more information; so SVM really should record information as
well.

Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxx>
---
 tools/xentrace/xenalyze.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index 46248e9a70..19b99dc66d 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -4641,6 +4641,14 @@ void hvm_generic_postprocess(struct hvm_data *h)
             {
             case VMEXIT_VINTR: /* Equivalent of PENDING_VIRT_INTR */
             case VMEXIT_PAUSE:
+                /*
+                 * VMX just has TRC_HVM_TRAP for these, which would be
+                 * redundant on SVM
+                 */
+            case VMEXIT_EXCEPTION_BP:
+            case VMEXIT_EXCEPTION_NM:
+            case VMEXIT_EXCEPTION_AC:
+            case VMEXIT_EXCEPTION_UD:
                 return;
             default:
                 break;
-- 
2.25.1




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.