On Mon, Aug 29, 2011 at 12:51 PM, Lluís <xscr...@gmx.net> wrote: > 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.
Well, fw_cfg is intended for very low level BIOS code. Virtual PCI devices would be better for OS level. > 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. This should be possible.
