Re: Recompile QEMU with frame-pointers
On 2021-01-27 15:14, Salvatore Mazzarino wrote: I’m trying to profile my QEMU process but what I get is a stack full of unknown. I would then need to recompile QEMU with -fno-omit-frame-pointer. Do you know if there is a version already built for that purpose? I am not sure, but I suspect that compiler-generated frame pointer code would interfere with the TCG compilation of tiny code snippets to be pasted together at runtime by the translated code generator. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
Re: [EXT] Re: Bugs in SSH module
On Wed, 27 Jan 2021 at 22:47, Berto Furth wrote: > I'm not sure but I think I *could* be seeing the problem. In the configure > log you're doing configure in the " ~/optee-qemu/qemu " directory > > sawyer@ubuntu:~/optee-qemu/qemu$ ./configure --disable-libssh > > But then in the make log you're doing make in a different directory called " > ~/optee-qemu/build " > > sawyer@ubuntu:~/optee-qemu/build$ make > makelog.txt > > It was my understanding that you have to run both in the same directory > otherwise the "make" might be using configuration files generated by a > different "configure" statement. With a 5.2-or-later QEMU (one using meson to build) then running configure/make in the source tree actually creates a build directory named "build" and uses that. But it's definitely clearer to explicitly create a build directory and run configure from that directory: the only supported thing is running both configure and make in the same place. > Can you try the following to clear out the "build" directory (or make a new > build directory), run configure from the build directory and then run make > from the same build directory? So for example... > > sawyer@ubuntu:~/optee-qemu/build$ rm -rf * > sawyer@ubuntu:~/optee-qemu/build$ ../qemu/configure --disable-libssh > sawyer@ubuntu:~/optee-qemu/build$ make "completely clean everything out and rerun from the beginning" seems like a good check to make, certainly. thanks -- PMM
Re: Recompile QEMU with frame-pointers
On Thu, 28 Jan 2021 at 08:42, Jakob Bohm wrote: > > On 2021-01-27 15:14, Salvatore Mazzarino wrote: > > I’m trying to profile my QEMU process but what I get is a stack full of > unknown. > > I would then need to recompile QEMU with -fno-omit-frame-pointer. > > Do you know if there is a version already built for that purpose? > > I am not sure, but I suspect that compiler-generated frame pointer > code would interfere with the TCG compilation of tiny code snippets > to be pasted together at runtime by the translated code generator. TCG has not worked by pasting together compiled snippets for many many years now. Compiling QEMU's C code with a frame pointer should be fine. You'll find that the JITted code looks like a single big function (ie there is no internal structure to it) but the entry-to-JIT prologue code should set up the frame pointer correctly so the stack frame looks like C helper function [JITted code] C code that called into JITted code There's no pre-built QEMU that was built with -fno-omit-frame-pointer because it would be pretty useless for anything except debugging QEMU itself, and if you're doing that you want to be working with the QEMU source code rather than a prebuilt binary anyway. You can easily build one yourself using configure's --extra-cflags option. thanks -- PMM
Need information about QEMU I2C
Hi all, I am currently trying to employ QEMU as testing device for ARM based machine (sabre lite). I don't have much information about QEMU's internal system that's why trying to reach someone with proper information. I want to learn how I2C device will work in QEMU in case of sabre lite machine? How can I read/write and set values for the device. My host OS is Ubuntu 18. Any information regarding this will be highly appreciated Thanks Kind Regards, Muhammad Salman Khalid Senior Embedded Software Engineer
Re: Recompile QEMU with frame-pointers
I have compiled QEMU with the following flags ../configure \ --enable-werror \ --enable-trace-backend=simple \ --enable-debug \ --target-list="x86_64-softmmu" \ --disable-gcrypt \ --enable-nettle \ --enable-docs \ --enable-fdt=system \ --enable-slirp=system \ --enable-capstone=system what I still get when I run perf command bcc/tools/profile is qemu-system-x86;[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown] 1 Any idea? On 27 January 2021 at 15:14:54, Salvatore Mazzarino (apocalips...@gmail.com) wrote: I’m trying to profile my QEMU process but what I get is a stack full of unknown. I would then need to recompile QEMU with -fno-omit-frame-pointer. Do you know if there is a version already built for that purpose? Thank you
Re: Recompile QEMU with frame-pointers
On Thu, 28 Jan 2021 at 18:08, Salvatore Mazzarino wrote: > > I have compiled QEMU with the following flags > > ../configure \ > --enable-werror \ > --enable-trace-backend=simple \ > --enable-debug \ > --target-list="x86_64-softmmu" \ > --disable-gcrypt \ > --enable-nettle \ > --enable-docs \ > --enable-fdt=system \ > --enable-slirp=system \ > --enable-capstone=system > > > what I still get when I run perf command bcc/tools/profile is > > > qemu-system-x86;[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown] > 1 Nope, because I have no idea what that profiling tool is looking at. You can check the executables that get built to see if they have the debug info you need in them. If the framepointer is the issue you can use --extra-cflags as I suggested. PS: run the executable in the build tree, not after install, because I have a feeling 'make install' might run 'strip' on it. thanks -- PMM
Re: Recompile QEMU with frame-pointers
Unfortunately it did not work. Here the flags ../configure \ --enable-werror \ --extra-cflags="-fno-omit-frame-pointer" \ --target-list="x86_64-softmmu" \ --disable-gcrypt \ --enable-nettle \ --enable-docs \ --enable-fdt=system \ --enable-slirp=system \ --enable-capstone=system And the profile I’m using is this https://github.com/iovisor/bcc/blob/master/tools/profile.py But the result I get is still profile -F 99 -d -f -K -p $(pgrep qemu) 20 qemu-system-x86;[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown] 1 qemu-system-x86;[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown] 1 qemu-system-x86;[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown] 1 qemu-system-x86;[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown] 1 On 28 January 2021 at 19:13:35, Peter Maydell (peter.mayd...@linaro.org) wrote: On Thu, 28 Jan 2021 at 18:08, Salvatore Mazzarino wrote: > > I have compiled QEMU with the following flags > > ../configure \ > --enable-werror \ > --enable-trace-backend=simple \ > --enable-debug \ > --target-list="x86_64-softmmu" \ > --disable-gcrypt \ > --enable-nettle \ > --enable-docs \ > --enable-fdt=system \ > --enable-slirp=system \ > --enable-capstone=system > > > what I still get when I run perf command bcc/tools/profile is > > > qemu-system-x86;[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown];[unknown] 1 Nope, because I have no idea what that profiling tool is looking at. You can check the executables that get built to see if they have the debug info you need in them. If the framepointer is the issue you can use --extra-cflags as I suggested. PS: run the executable in the build tree, not after install, because I have a feeling 'make install' might run 'strip' on it. thanks -- PMM
[QEMU TCG] Qeustion about the PCID Feature in TCG
Hi,
I am running QEMU in TCG mode (my server doesn't have kvm support), and I
am getting the memory traces in a x86 guest machine of all memory accesses,
including the PCID (process-context identifier, and I need that for my
current research), on a linux host. I have seen the TCG PCID feature flag
is commented out in target/i386/cpu.c, and if I directly emulate a CPU
which has PCID flag I got the warning:
warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
so I uncommented the CPUID_EXT_PCID in TCG_EXT_FEATURES, and
the CPUID_7_0_EBX_INVPCID in TCG_7_0_EBX_FEATURES, in target/i386/cpu.c. I
have seen the PCID in the cr3 register in cpu get set, my question is that
I am not sure if there will be any issues with this flag. Why is it
commented out by default?
Just in case, I will put my commands here. Here are my configurations for
compiling:
*./configure --prefix=/tigress/kaifengx/sysroot/
--target-list=x86_64-softmmu,x86_64-linux-user --disable-kvm --disable-vnc
--enable-gtk --enable-plugins*
And my command for running the QEMU:
*qemu-system-x86_64 \*
*-cpu qemu64,+pcid\-m 4G \-icount shift=0 \-drive
if=virtio,file=${DISK},cache=none \-device pqii \-trace
events=`pwd`/events \-D ${LOG_FILE} \-net
user,hostfwd=tcp::10022-:22 \-net nic \-display none \
-nographic \-plugin QEMU_PATH/tests/plugin/libtlb.so,arg=inline,arg=io*
--
Kaifeng Xu
Electrical Engineering
Princeton University
Email: kaife...@princeton.edu
Mobile Phone: 6094011564
