From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53481) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QyTWD-0007aK-Pn for qemu-devel@nongnu.org; Tue, 30 Aug 2011 14:58:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QyTWC-0001uK-Rn for qemu-devel@nongnu.org; Tue, 30 Aug 2011 14:58:41 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:60339) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QyTWC-0001uG-PX for qemu-devel@nongnu.org; Tue, 30 Aug 2011 14:58:40 -0400 Received: by qwj8 with SMTP id 8so4667718qwj.4 for ; Tue, 30 Aug 2011 11:58:40 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <87wrdwfkio.fsf@ginnungagap.bsc.es> References: <87wrdwfkio.fsf@ginnungagap.bsc.es> From: Blue Swirl Date: Tue, 30 Aug 2011 18:58:19 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH, RFC] trace: implement guest tracepoint passthrough List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi , Blue Swirl , =?UTF-8?B?TGx1w61z?= , Dhaval Giani , Stefan Hajnoczi , qemu-devel On Mon, Aug 29, 2011 at 12:51 PM, Llu=C3=ADs wrote: > Stefan Hajnoczi writes: > >> The ability to trace from the guest can be handy, so I think we should >> have this feature. =C2=A0Please 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. =C2=A0The guest code needs to= be >> built with QEMU and they may not function with other QEMU builds or >> guest builds. =C2=A0This is fine for development but not feasible when Q= EMU >> 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. =C2=A0This 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.