Xentrace

From Xen
Revision as of 19:32, 26 September 2014 by Dslutz (talk | contribs) (Created page with "But what we want in upstream is something that will help us in production. For that to be useful, we need the logging to be as efficient as possible. Every additional HVM trace …")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

But what we want in upstream is something that will help us in production. For that to be useful, we need the logging to be as efficient as possible. Every additional HVM trace point potentially adds more data to someone else's HVM trace. So we don't want extraneous information, and we don't want to log something that we can infer from something else.

In general, it's enough to give information about the decisions that Xen is making to infer what the previous state is; and then giving information about what Xen did in response (i.e., return values, injection of traps, &c) to help figure out how the guest responded.