Stefan Hajnoczi writes: > The ability to trace from the guest can be handy, so I think we should > have this feature. Please add documentation on how to hook it up > (e.g. how people would use this for other firmware/guest code and/or > other architectures).
> Guest and QEMU need to agree on event IDs. The guest code needs to be > built with QEMU and they may not function with other QEMU builds or > guest builds. This is fine for development but not feasible when QEMU > and the guest code are built or provided separately. > I suggest we merge this as a development feature that can be used when > bringing up new architectures, debugging guest code, or for some types > of performance work. This feature falls under the Do-It-Yourself > area, where things could break relatively easy but developers who wish > to use it should be able to get it working in their area. This sounds is indeed interesting. I suppose I could even use this as a backdoor mechanism for the guest to communicate with QEMU. The only problem I see is that fw_cfg is one-way (i.e., QEMU cannot return any data back to the guest), as opposed to a backdoor mechanism based on a virtual device or "magic" instructions. Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
