From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59130) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBj6q-0004TF-Cm for qemu-devel@nongnu.org; Tue, 20 Aug 2013 06:24:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VBj6j-0000x6-2H for qemu-devel@nongnu.org; Tue, 20 Aug 2013 06:24:20 -0400 Received: from mail-ob0-f180.google.com ([209.85.214.180]:38281) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBj6i-0000wl-TZ for qemu-devel@nongnu.org; Tue, 20 Aug 2013 06:24:12 -0400 Received: by mail-ob0-f180.google.com with SMTP id up14so273344obb.39 for ; Tue, 20 Aug 2013 03:24:11 -0700 (PDT) Date: Tue, 20 Aug 2013 03:38:41 -0500 From: Rob Landley In-Reply-To: <1376834228.65699.YahooMailNeo@web172602.mail.ir2.yahoo.com> (from dacian_herbei@yahoo.fr on Sun Aug 18 08:57:08 2013) Message-Id: <1376987921.2737.64@driftwood> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] minimal linux distribution for qemu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Herbei Dacian Cc: QEmu Devel On 08/18/2013 08:57:08 AM, Herbei Dacian wrote: >=20 > good to know. > I was working back in 2005-2006 with a company that had a 4MB kernel. > At that time I was too inexperienced to work at that level but I =20 > thought now I could reproduce their work with some help. > Anyhow for the moment I'll go for 256 MB of ram board just so that I =20 > don't worry too much about things that are not yet relevant for me. > But thanks again for the warning. > But since you helped me soo much I have another question. > Is it fisible to change the emulator so that I may visualize the =20 > following aspects: > _ address of the currently executed instruction from the guest system > _ if this instruction is a form of jump like call return conditional =20 > jump. > _ the address or range of addresses read by this instruction > _ the address or range of addresses written by this instruction If you feed qemu the -s option it'll open a network port you can =20 connect to to provide the gdbserver protocol (gdb's "target remote" =20 command attaches to this). For system emulation it acts like a jtag =20 attached to the emulated hardware, letting you see registers and such. > I read some things about the emulator and if I understood it =20 > correctly the emulator > breaks the instructions of the gurest platform in micro ops which are =20 > then executed > on the host operation system. Not really, no. QEMU translates large blocks of code (used to be pages, now it's =20 variable sized chunks depending on where the return instruction is) and =20 keeps the translated versions cached (sort of like a java JIT). The =20 main QEMU loop then calls the translated functions which execute until =20 they return or get interrupted by signals (simulating things like timer =20 IRQ). This is why QEMU is so fast, the actual translation overhead is =20 amortized by the resulting native code being run lots of times, a =20 function or loop gets translated once and then runs as native code. This means that "the address of the currently executing instruction" =20 isn't really something qemu naturally tracks, because although there =20 _is_ a copy of the untranslated code page, it's not what we're running. =20 The gdbserver code tries to do so artifically, but it's slow and =20 awkward and not always perfect. Self-modifying code is actually a horrible thing to do to qemu, from a =20 performance perspective. Every time the emulated code page is modified, =20 the cached copy of the translated code is discarded and the entire page =20 gets retranslated. This means that in Aboriginal Linux, the shell =20 scripts ./configure runs sped up 20% when I replaced my dynamically =20 linked busybox with a statically linked one, due to the extra =20 translations caused by the relocation fixups. Rob=