| Message ID | 20240626133853.4150731-6-george.dunlap@cloud.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | AMD Nested Virt Preparation | expand |
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;
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@cloud.com> --- tools/xentrace/xenalyze.c | 8 ++++++++ 1 file changed, 8 insertions(+)