Re: [Qemu-devel] Round robin of multi-vcpu in qemu
I've examined the alarm timmer, this timer is used to interrupt the execution of VCPUs to handle interruptions. IIRC, alarm timer will interrupt VCPU to execute the next one. You can check where QEMU register the alarm timer, and see how it works. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] QEMU Exception Handling
On Fri, Apr 12, 2013 at 03:14:48PM -0700, Anand Brooks wrote: Hello All, I ran into an error when testing some code that would generate protection faults. I had my exception handler setup so that it expected the EIP and Stack not to change, standard behavior on native CPU. But on QEMU both the ESP and EIP are changed at fault generation time. I remember if exception occured, QEMU have to re-translate the translation block to locate what PC triggers that exception. The reason behind that is QEMU won't keep exact PC during the translation (you have to update PC after each guest instruction, which cost too much). So I guess you can check follow the control flow and see when/where QEMU get the correct PC, then call your exception handler instead, not QEMU's one. HTH, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH] translate: optimize gen_intermediate_code_internal
)
-tcg_ctx.gen_opc_instr_start[lj++] = 0;
+while (++lj = j) {
+tcg_ctx.gen_opc_instr_start[lj] = 0;
+}
} else {
tb-size = ctx.pc - pc_start;
tb-icount = num_insns;
--
1.7.2.5
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH] translate: optimize gen_intermediate_code_internal
On Tue, Apr 09, 2013 at 10:11:37AM +0200, Paolo Bonzini wrote: Il 09/04/2013 10:05, 陳韋任 (Wei-Ren Chen) ha scritto: Hi liguang, Just to be curious, how much performance improvement this patch can get? I think zero. It is indeed making the code a tiny bit more readable in the 2nd/3rd/5th/6th hunks. Then I think the subject should be changed from optimize to readable. Optimize is a kind of misleading... But the 1st and 4th hunks, which do -num_insns = 0; are wrong. I'm surprised the compiler doesn't report usage of an uninitialized variable. liguang, how did you test them? Paolo Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH] translate: optimize gen_intermediate_code_internal
Hi liguang, On Tue, Apr 09, 2013 at 04:21:10PM +0800, li guang wrote: 在 2013-04-09二的 10:11 +0200，Paolo Bonzini写道： Il 09/04/2013 10:05, 陳韋任 (Wei-Ren Chen) ha scritto: Hi liguang, Just to be curious, how much performance improvement this patch can get? I think zero. It is indeed making the code a tiny bit more readable in the 2nd/3rd/5th/6th hunks. I think maybe a little greater than 0, for it optimizes a variable 'lj' increment. As Peter said, only profiling can show if there is a performance improvement. But the 1st and 4th hunks, which do -num_insns = 0; are wrong. I'm surprised the compiler doesn't report usage of an uninitialized variable. liguang, how did you test them? I do normal compile and run guest OS for TCG, I think 'max_insns = tb-cflags CF_COUNT_MASK;' is enough to feed compiler. num_insns and max_insns are two different variables, right? So this assignment does not do anything with num_insns. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH] translate: optimize gen_intermediate_code_internal
Hi liguang, OK, thanks! but, please make no mistake, I'm not saying this patch promote performance of TCG, this just optimize code writing of this function, of course code writing is not deemed to promote its performance. or, we shouldn't do any code change if they benefit little in performance? IMO, if you are saying the patch can improve performance, then you should run benchmark to convince others. If your patch is trying to make code clear, then optimize might not be a good term to describe your patch. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH] translate: optimize gen_intermediate_code_internal
you're right, seems the word 'optimize' is not good here. but what should I use? you know, even compiler like gcc will use -O for code optimization. translate: code cleanup in gen_intermediate_code_internal would be better, I think. :) Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] GSoC 2013, Introduce API to query IP addresses for given domain Libvirt project
On Wed, Apr 10, 2013 at 04:46:45AM +0200, Tabibel Sami wrote: Hello, I am doing master degree of Cryptology and information security I have good C and Python skills, and i am interested to work on Introduce API to query IP addresses for given domain Libvirt project. I am looking for any comment about the difficulty and the content of the project, and also about my chances to be accepted if i apply for. As a libvirt user, I would give it a +1. Currently I have to use `arp -n` on the host to checkout VM's ip. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] win32 qemu binaries
Hi Michael, On Fri, Mar 29, 2013 at 07:53:47PM +0800, Michael W. Bombardieri wrote: Hi, Thanks for your work on Qemu! My friend Prashant Satish has provided Qemu binaries for 1.4.0 hosted here: http://www.omledom.com/ Currently there is no support for SDL in the build but more binary releases are to come. Would it be possible for this mirror to be added to: http://wiki.qemu.org/Links#Unofficial_QEMU_binaries Good work and thanks! I have added the link to wiki page. Could you guys add more information on your website (mention no support for SDL, for example). Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] large memory requirements for translate.c a barrier
Still no joy: PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND 21212 todd -5 20 1142M 118M sleep/0 - 1:03 37.30% cc1 cc -I. -I/home/todd/git/sw/3rdParty/qemu -I/home/todd/git/sw/3rdParty/qemu/include -I/home/todd/git/sw/3rdParty/qemu/tcg -I/home/todd/git/sw/3rdParty/qemu/tcg/i386 -fPIE -DPIE -m32 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/usr/local/include -I/usr/X11R6/include -Wno-redundant-decls -DTIME_MAX=INT_MAX -fno-gcse -fno-var-tracking -fstack-protector-all -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wold-style-definition -I/usr/local/include/libpng -I/usr/X11R6/include/pixman-1 -DHAS_AUDIO -DHAS_AUDIO_CHOICE -I/home/todd/git/sw/3rdParty/qemu/target-i386 -Itarget-i386 -I.. -I/home/todd/git/sw/3rdParty/qemu/target-i386 -DNEED_CPU_H -I/home/todd/git/sw/3rdParty/qemu/include -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -MMD -MP -MT target-i386/kvm-stub.o -MF target-i386/kvm-stub.d -O2 -D_FORTIFY_SOURCE=2 -g -c -o target-i386/kvm-stub.o /home/todd/git/sw/3rdParty/qemu/target-i386/kvm-stub.c Is it possible to update your GCC, or try to use clang? HTH, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
[Qemu-devel] [PATCH v3] Use proper term in TCG README
In TCG, target means the host architecture for which TCG generates the code. Using guest rather than target to make the document more consistent. Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw --- v3: Adopt Peter's suggestion on sentence and typo. v2: Correct all wrong usage of the term target in this document. tcg/README | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/tcg/README b/tcg/README index 934e7af..063aeb9 100644 --- a/tcg/README +++ b/tcg/README @@ -14,6 +14,10 @@ the emulated architecture. As TCG started as a generic C backend used for cross compiling, it is assumed that the TCG target is different from the host, although it is never the case for QEMU. +In this document, we use guest to specify what architecture we are +emulating; target always means the TCG target, the machine on which +we are running QEMU. + A TCG function corresponds to a QEMU Translated Block (TB). A TCG temporary is a variable only live in a basic @@ -379,7 +383,7 @@ double-word product T0. The later is returned in two single-word outputs. Similar to mulu2, except the two inputs T1 and T2 are signed. -* 64-bit target on 32-bit host support +* 64-bit guest on 32-bit host support The following opcodes are internal to TCG. Thus they are to be implemented by 32-bit host code generators, but are not to be emitted by guest translators. @@ -521,9 +525,9 @@ register. a better generated code, but it reduces the memory usage of TCG and the speed of the translation. -- Don't hesitate to use helpers for complicated or seldom used target +- Don't hesitate to use helpers for complicated or seldom used guest instructions. There is little performance advantage in using TCG to - implement target instructions taking more than about twenty TCG + implement guest instructions taking more than about twenty TCG instructions. Note that this rule of thumb is more applicable to helpers doing complex logic or arithmetic, where the C compiler has scope to do a good job of optimisation; it is less relevant where @@ -531,9 +535,9 @@ register. inline TCG may still be faster for longer sequences. - The hard limit on the number of TCG instructions you can generate - per target instruction is set by MAX_OP_PER_INSTR in exec-all.h -- + per guest instruction is set by MAX_OP_PER_INSTR in exec-all.h -- you cannot exceed this without risking a buffer overrun. - Use the 'discard' instruction if you know that TCG won't be able to prove that a given global is dead at a given program point. The - x86 target uses it to improve the condition codes optimisation. + x86 guest uses it to improve the condition codes optimisation. -- 1.7.12.3 -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH] Use proper term in TCG README
On Fri, Mar 08, 2013 at 11:13:24AM +0100, Stefan Hajnoczi wrote: On Fri, Mar 08, 2013 at 05:29:29PM +0800, Peter Maydell wrote: On 8 March 2013 17:21, Stefan Hajnoczi stefa...@gmail.com wrote: On Thu, Mar 07, 2013 at 11:33:01AM +0800, 陳韋任 (Wei-Ren Chen) wrote: In TCG, target means the host architecture for which TCG generates the code. Using guest rather than target to make the document more consistent. @@ -379,7 +379,7 @@ double-word product T0. The later is returned in two single-word outputs. Similar to mulu2, except the two inputs T1 and T2 are signed. -* 64-bit target on 32-bit host support +* 64-bit guest on 32-bit host support The following opcodes are internal to TCG. Thus they are to be implemented by 32-bit host code generators, but are not to be emitted by guest translators. Review from TCG experts please. It seems we have multiple meanings for target (e.g. ./configure --target-list= does not mean the host architecture for which TCG generates code), if this is really the way TCG uses the term then fine. Yes, this is an unfortunate terminology clash, but in a TCG context 'target' does mean 'host architecture which the backend compiles for' (see the tcg/README definition in section 2). This is partly because of TCG's history as a C compiler backend, where 'target' is unambiguous and may be different from the 'host' architecture the compiler itself executes on. There are several places in tcg/README which use 'target' in the sense 'QEMU target, ie guest' (as well as lots of uses in the 'TCG target, ie host' sense), not just this one; it might be a good idea to put a note in the Definitions section that this document uses 'guest' when it means what in other areas of QEMU is often referred to as the 'target', and fix the places where we've accidentally used 'target' and 'guest would be better. Wei-Ren, can you please convert the other instances in tcg/README where 'target' is used in the 'guest' sense, too? I will look into the tcg/README again. :) Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
[Qemu-devel] [PATCH v2] Use proper term in TCG README
In TCG, target means the host architecture for which TCG generates the code. Using guest rather than target to make the document more consistent. Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw --- tcg/README | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/tcg/README b/tcg/README index 934e7af..00d4751 100644 --- a/tcg/README +++ b/tcg/README @@ -14,6 +14,9 @@ the emulated architecture. As TCG started as a generic C backend used for cross compiling, it is assumed that the TCG target is different from the host, although it is never the case for QEMU. +In this document, we uses guest to specify what architecture we are +emulating, and target means on what machine we are running QEMU. + A TCG function corresponds to a QEMU Translated Block (TB). A TCG temporary is a variable only live in a basic @@ -379,7 +382,7 @@ double-word product T0. The later is returned in two single-word outputs. Similar to mulu2, except the two inputs T1 and T2 are signed. -* 64-bit target on 32-bit host support +* 64-bit guest on 32-bit host support The following opcodes are internal to TCG. Thus they are to be implemented by 32-bit host code generators, but are not to be emitted by guest translators. @@ -521,9 +524,9 @@ register. a better generated code, but it reduces the memory usage of TCG and the speed of the translation. -- Don't hesitate to use helpers for complicated or seldom used target +- Don't hesitate to use helpers for complicated or seldom used guest instructions. There is little performance advantage in using TCG to - implement target instructions taking more than about twenty TCG + implement guest instructions taking more than about twenty TCG instructions. Note that this rule of thumb is more applicable to helpers doing complex logic or arithmetic, where the C compiler has scope to do a good job of optimisation; it is less relevant where @@ -531,9 +534,9 @@ register. inline TCG may still be faster for longer sequences. - The hard limit on the number of TCG instructions you can generate - per target instruction is set by MAX_OP_PER_INSTR in exec-all.h -- + per guest instruction is set by MAX_OP_PER_INSTR in exec-all.h -- you cannot exceed this without risking a buffer overrun. - Use the 'discard' instruction if you know that TCG won't be able to prove that a given global is dead at a given program point. The - x86 target uses it to improve the condition codes optimisation. + x86 guest uses it to improve the condition codes optimisation. -- 1.7.12.3
Re: [Qemu-devel] [PATCH v2] Use proper term in TCG README
Thanks, Peter. On Thu, Mar 14, 2013 at 09:03:15AM +, Peter Maydell wrote: On 14 March 2013 08:06, 陳韋任 (Wei-Ren Chen) che...@iis.sinica.edu.tw wrote: In TCG, target means the host architecture for which TCG generates the code. Using guest rather than target to make the document more consistent. Thanks. I've tweaked the wording a little in one sentence below; otherwise it looks good. Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw --- tcg/README | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/tcg/README b/tcg/README index 934e7af..00d4751 100644 --- a/tcg/README +++ b/tcg/README @@ -14,6 +14,9 @@ the emulated architecture. As TCG started as a generic C backend used for cross compiling, it is assumed that the TCG target is different from the host, although it is never the case for QEMU. +In this document, we uses guest to specify what architecture we are use. +emulating, and target means on what machine we are running QEMU. emulating; target always means the TCG target, the machine on which we are running QEMU. + A TCG function corresponds to a QEMU Translated Block (TB). A TCG temporary is a variable only live in a basic @@ -379,7 +382,7 @@ double-word product T0. The later is returned in two single-word outputs. Similar to mulu2, except the two inputs T1 and T2 are signed. -* 64-bit target on 32-bit host support +* 64-bit guest on 32-bit host support The following opcodes are internal to TCG. Thus they are to be implemented by 32-bit host code generators, but are not to be emitted by guest translators. @@ -521,9 +524,9 @@ register. a better generated code, but it reduces the memory usage of TCG and the speed of the translation. -- Don't hesitate to use helpers for complicated or seldom used target +- Don't hesitate to use helpers for complicated or seldom used guest instructions. There is little performance advantage in using TCG to - implement target instructions taking more than about twenty TCG + implement guest instructions taking more than about twenty TCG instructions. Note that this rule of thumb is more applicable to helpers doing complex logic or arithmetic, where the C compiler has scope to do a good job of optimisation; it is less relevant where @@ -531,9 +534,9 @@ register. inline TCG may still be faster for longer sequences. - The hard limit on the number of TCG instructions you can generate - per target instruction is set by MAX_OP_PER_INSTR in exec-all.h -- + per guest instruction is set by MAX_OP_PER_INSTR in exec-all.h -- you cannot exceed this without risking a buffer overrun. - Use the 'discard' instruction if you know that TCG won't be able to prove that a given global is dead at a given program point. The - x86 target uses it to improve the condition codes optimisation. + x86 guest uses it to improve the condition codes optimisation. -- 1.7.12.3 -- PMM -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH v6 08/24] hw/arm: add Faraday FTRTC011 RTC timer support
On Thu, Mar 07, 2013 at 02:41:26AM -0500, Paolo Bonzini wrote:
From Makefile.target, qtest is built when you build softmmu target.
I guess there is no need to add --enable-qtest option. However, I
don't know how to run qtest...
make check-qtest-arm
O.K., let me try to summarize the working flow..
$ ../configure --target-list=i386-softmmu
$ make; make install
$ make check-qtest-i386
$ cd tests
$ export QTEST_QEMU_BINARY=/path/to/qemu-system-i386
$ ./rtc-test
/i386/rtc/check-time/bcd: OK
/i386/rtc/check-time/dec: OK
/i386/rtc/alarm/interrupt: OK
...
Developers should add their test into ${QEMU_SRC}/tests . Am I right?
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] qemu-img do not verify encrytption
On Thu, Mar 07, 2013 at 06:57:19PM +0800, yue-kvm wrote: hi stefan: [root@kvm ~]# qemu-img -V qemu-img version 0.12.1, Copyright (c) 2004-2008 Fabrice Bellard Hrm..., 0.12 is too old, why don't you use newer version? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] QEmu TCG SIMD extension?
On Wed, Mar 06, 2013 at 11:47:58AM +0800, Peter Maydell wrote: On 6 March 2013 11:30, 陳韋任 (Wei-Ren Chen) che...@iis.sinica.edu.tw wrote: While searching for QEMU SIMD issues, I found there was a paper presented in 2011 [1], and the source code is also public on [2]. However, it seems this project doesn't make any progress since last year. I update their change to upstream and you can download from here: $ git clone git://github.com/azru0512/qemu.git -b neon-simd Sadly, it can not boot the kernel image provided on [2]. Anyway, I found there was only one thread has discussion on their work [3]. I want to hear more feedback on their idea on adding SIMD TCG IR. I think my opinions are still the same -- interesting idea, but getting it to work with a set of IR ops which aren't target or host specific and getting it to give correct bit-for-bit results, rounding, flags, etc, is likely to be tricky. It would also be important to determine first whether Neon (or other SIMD) emulation performance is truly a major bottleneck. I found the problem and now it can boot the kernel image and run the test. The authors claim they design the general SIMD IR after studying various SIMD ISA. I am not an expert, and only can decide if it's true or not by writing another frontend. Well, one of reasons I am studying their work is to see SIMD IR could benifit our QEMU+LLVM binary translator. ;) Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
[Qemu-devel] [PATCH] Use proper term in TCG README
In TCG, target means the host architecture for which TCG generates the code. Using guest rather than target to make the document more consistent. Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw --- tcg/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tcg/README b/tcg/README index 934e7af..22174c0 100644 --- a/tcg/README +++ b/tcg/README @@ -379,7 +379,7 @@ double-word product T0. The later is returned in two single-word outputs. Similar to mulu2, except the two inputs T1 and T2 are signed. -* 64-bit target on 32-bit host support +* 64-bit guest on 32-bit host support The following opcodes are internal to TCG. Thus they are to be implemented by 32-bit host code generators, but are not to be emitted by guest translators. -- 1.7.12.3
Re: [Qemu-devel] [PATCH v6 08/24] hw/arm: add Faraday FTRTC011 RTC timer support
Excuse me, could you please show me the way how to build the test cases and launch the test case. I do have found a web page to qtest at the following link: http://wiki.qemu.org/Features/QTest But it's wrong at both 'build/example usage' and 'Additional Details/Status', please see the logs bellow: dante@vmware:/pub/qemu$ ./configure --target-list=arm-softmmu --audio-drv-list=oss alsa sdl --enable-qtest ERROR: unknown option --enable-qtest dante@vmware:/pub/qemu$ ./arm-softmmu/qemu-system-arm -test ? qemu-system-arm: -test: invalid option From Makefile.target, qtest is built when you build softmmu target. I guess there is no need to add --enable-qtest option. However, I don't know how to run qtest... Stefan (Cc'ed), I think we should cleanup QTest wiki page, right? ;) Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
[Qemu-devel] QEmu TCG SIMD extension?
Hi all, While searching for QEMU SIMD issues, I found there was a paper presented in 2011 [1], and the source code is also public on [2]. However, it seems this project doesn't make any progress since last year. I update their change to upstream and you can download from here: $ git clone git://github.com/azru0512/qemu.git -b neon-simd Sadly, it can not boot the kernel image provided on [2]. Anyway, I found there was only one thread has discussion on their work [3]. I want to hear more feedback on their idea on adding SIMD TCG IR. [1] http://adt.cs.upb.de/quf/quf11/quf2011_12.pdf [2] http://tima-sls.imag.fr/www/research/qemu/simd-qemu/ [3] http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg02065.html Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] default guest RAM size?
On Tue, Mar 05, 2013 at 01:40:38PM +0800, Peter Maydell wrote: On 5 March 2013 13:26, Michael Tokarev m...@tls.msk.ru wrote: For many years, qemu defaults to 128Mb of guest RAM size. Today, this is just too small, and many OSes fails to boot with this size, more, they fail to produce any reasonable messages either (eg, windows7 just crashes at startup). If you make the default bigger then some boards will crash or behave weirdly because they try to map more RAM in than will fit into the space for RAM in their address maps. So, 128Mb is still a good default? I am just wondering if those boards with little memory still are major user of QEMU? :) Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] QEMU Profiling
On Tue, Feb 26, 2013 at 05:16:48PM +0400, Евард Вадим wrote: Hi list, Our team is now surveying various binary translation and emulation tools, and as part of this work we have to measure time spent in different parts of the process. More precisely, I'd like to make this work on x86_64-linux-user qemu without any accelerations. If article [1] is still relevant, I see the following places to spend time: 1. Locate end of translation block 2. Disassemble it to IR 3. Assemble x86_64 machine code 4. Execute it 5. Process syscalls 6. .. What else? The flow above is right, I would suggest you reading the source code to get more familar with QEMU. What is the best method to measure these times you'd suggest? ./configure mentions 4 things I found relevant: 1. --enable-debug-tcg (didn't look at it yet) 2. --enable-trace-backend=B 3. --enable-profiler (some things like qemu_time seem relevant, didn't look closely yet) 4. --enable-gprof (I encountered problems when building and/or running qemu with gprof) You can get profiling about QEMU itself by using usual measurement, I guess. The problem is how you get the time spent is the code cache. I guess you have to spot where QEMU jump into the code cache, and when/where it leave the code cache. Then insert your profiling code there. HTH, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system
Do you mean the git of git://xenbits.xen.org/staging/qemu-upstream-unstable.git ? ./configure reports: glib-2.12 required to compile QEMU; but the latest version is glib-1.2.10-20.el5.x86_64 for kernel 2.6.18-274.3.1.el5xen. How to make and use the latest qemu from qemu.git? Please against git://git.qemu-project.org/qemu.git , you can see the link from [1]. You will need to install packages required by QEMU before you building it. Besides, the patch is a little big and the patch now can't be completely inserted into the latest qemu-upstream so that fully conforming to the CODING_STYLE is not a little work, if anyone is interested in the feature, welcome to join in the work. That might be a hint that you need to split your patch into smaller pieces. :) Regards, chenwj [1] http://wiki.qemu.org/Download -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system
I need to be against qemu-xen source tree who will exist in xen source tree as ioemu-qemu-xen. Some packages can't be found by yum at cenos5. Not familiar with qemu-xen, but from this link [1] I think qemu-xen also use the same upstream I mentioned before? If you can install that packages with yum, then download and build it yourself. You can download glib from here [2]. Regards, chenwj [1] http://wiki.xen.org/wiki/QEMU_Upstream [2] http://ftp.gnome.org/pub/gnome/sources/glib/2.34/ -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH V2 1/3] HMP: add QDict to info callback handler
do_info_mtree(Monitor *mon)
+static void do_info_mtree(Monitor *mon, const QDict *qdict)
{
mtree_info((fprintf_function)monitor_printf, mon);
}
-static void do_info_numa(Monitor *mon)
+static void do_info_numa(Monitor *mon, const QDict *qdict)
{
int i;
CPUArchState *env;
@@ -1802,7 +1802,7 @@ static void do_info_numa(Monitor *mon)
int64_t qemu_time;
int64_t dev_time;
-static void do_info_profile(Monitor *mon)
+static void do_info_profile(Monitor *mon, const QDict *qdict)
{
int64_t total;
total = qemu_time;
@@ -1816,7 +1816,7 @@ static void do_info_profile(Monitor *mon)
dev_time = 0;
}
#else
-static void do_info_profile(Monitor *mon)
+static void do_info_profile(Monitor *mon, const QDict *qdict)
{
monitor_printf(mon, Internal profiler not compiled\n);
}
@@ -1825,7 +1825,7 @@ static void do_info_profile(Monitor *mon)
/* Capture support */
static QLIST_HEAD (capture_list_head, CaptureState) capture_head;
-static void do_info_capture(Monitor *mon)
+static void do_info_capture(Monitor *mon, const QDict *qdict)
{
int i;
CaptureState *s;
diff --git a/net/net.c b/net/net.c
index dbf3e1b..354d292 100644
--- a/net/net.c
+++ b/net/net.c
@@ -852,7 +852,7 @@ void print_net_client(Monitor *mon, NetClientState *nc)
NetClientOptionsKind_lookup[nc-info-type],
nc-info_str);
}
-void do_info_network(Monitor *mon)
+void do_info_network(Monitor *mon, const QDict *qdict)
{
NetClientState *nc, *peer;
NetClientOptionsKind type;
diff --git a/net/slirp.c b/net/slirp.c
index c14259f..4df550f 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -670,7 +670,7 @@ static int slirp_guestfwd(SlirpState *s, const char
*config_str,
return -1;
}
-void do_info_usernet(Monitor *mon)
+void do_info_usernet(Monitor *mon, const QDict *qdict)
{
SlirpState *s;
diff --git a/savevm.c b/savevm.c
index bcdb92e..720eea6 100644
--- a/savevm.c
+++ b/savevm.c
@@ -2371,7 +2371,7 @@ void do_delvm(Monitor *mon, const QDict *qdict)
}
}
-void do_info_snapshots(Monitor *mon)
+void do_info_snapshots(Monitor *mon, const QDict *qdict)
{
BlockDriverState *bs, *bs1;
QEMUSnapshotInfo *sn_tab, *sn, s, *sn_info = s;
diff --git a/vl.c b/vl.c
index e6a8d89..1905266 100644
--- a/vl.c
+++ b/vl.c
@@ -1263,7 +1263,7 @@ void pcmcia_socket_unregister(PCMCIASocket *socket)
}
}
-void pcmcia_info(Monitor *mon)
+void pcmcia_info(Monitor *mon, const QDict *qdict)
{
struct pcmcia_socket_entry_s *iter;
--
1.7.1
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
[Qemu-devel] [PATCH v3] translate-all.c: Use tb1-phys_hash_next directly in tb_remove
When tb_remove was first commited at fd6ce8f6, there were three different
calls pass different names to offsetof. In current codebase, the other two
calls are replaced with tb_page_remove. There is no need to have a general
tb_remove. Omit passing the third parameter and using tb1-phys_hash_next
directly.
Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw
---
v3: Rebasing
v2: Address Peter's comment.
- place comment used belong tb_remove above tb_phys_invalidate.
- remove unnecessary bracket.
translate-all.c | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/translate-all.c b/translate-all.c
index b621748..d367fc4 100644
--- a/translate-all.c
+++ b/translate-all.c
@@ -759,19 +759,17 @@ static void tb_page_check(void)
#endif
-/* invalidate one TB */
-static inline void tb_remove(TranslationBlock **ptb, TranslationBlock *tb,
- int next_offset)
+static inline void tb_hash_remove(TranslationBlock **ptb, TranslationBlock *tb)
{
TranslationBlock *tb1;
for (;;) {
tb1 = *ptb;
if (tb1 == tb) {
-*ptb = *(TranslationBlock **)((char *)tb1 + next_offset);
+*ptb = tb1-phys_hash_next;
break;
}
-ptb = (TranslationBlock **)((char *)tb1 + next_offset);
+ptb = tb1-phys_hash_next;
}
}
@@ -828,6 +826,7 @@ static inline void tb_reset_jump(TranslationBlock *tb, int
n)
tb_set_jmp_target(tb, n, (uintptr_t)(tb-tc_ptr + tb-tb_next_offset[n]));
}
+/* invalidate one TB */
void tb_phys_invalidate(TranslationBlock *tb, tb_page_addr_t page_addr)
{
CPUArchState *env;
@@ -839,8 +838,7 @@ void tb_phys_invalidate(TranslationBlock *tb,
tb_page_addr_t page_addr)
/* remove the TB from the hash list */
phys_pc = tb-page_addr[0] + (tb-pc ~TARGET_PAGE_MASK);
h = tb_phys_hash_func(phys_pc);
-tb_remove(tb_phys_hash[h], tb,
- offsetof(TranslationBlock, phys_hash_next));
+tb_hash_remove(tb_phys_hash[h], tb);
/* remove the TB from the page list */
if (tb-page_addr[0] != page_addr) {
--
1.7.3.4
Re: [Qemu-devel] [PATCH] target-mips: Use EXCP_SC rather than a magic number
ping? :-)
On Tue, Dec 11, 2012 at 12:15:55AM +0800, 陳韋任 (Wei-Ren Chen) wrote:
From the discussion on the ML [1], the exception limit defined by
magic number 0x100 is actually EXCP_SC defined in cpu.h. Replace the
magic number with EXCP_SC. Remove #if 1 .. #endif as well.
[1] http://lists.gnu.org/archive/html/qemu-devel/2012-11/msg03080.html
Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw
---
target-mips/op_helper.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/target-mips/op_helper.c b/target-mips/op_helper.c
index f45d494..98a445c 100644
--- a/target-mips/op_helper.c
+++ b/target-mips/op_helper.c
@@ -39,10 +39,10 @@ static inline void QEMU_NORETURN
do_raise_exception_err(CPUMIPSState *env,
uintptr_t pc)
{
TranslationBlock *tb;
-#if 1
-if (exception 0x100)
+if (exception EXCP_SC) {
qemu_log(%s: %d %d\n, __func__, exception, error_code);
-#endif
+}
+
env-exception_index = exception;
env-error_code = error_code;
--
1.7.3.4
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH v2] exec.c: Use tb1-phys_hash_next directly in tb_remove
On Tue, Dec 18, 2012 at 05:37:53PM +0100, Stefan Hajnoczi wrote: On Wed, Nov 21, 2012 at 07:52:48AM +0800, 陳韋任 (Wei-Ren Chen) wrote: When tb_remove was first commited at fd6ce8f6, there were three different calls pass different names to offsetof. In current codebase, the other two calls are replaced with tb_page_remove. There is no need to have a general tb_remove. Omit passing the third parameter and using tb1-phys_hash_next directly. Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw --- v2: Address Peter's comment. - place comment used belong tb_remove above tb_phys_invalidate. - remove unnecessary bracket. exec.c | 12 +--- 1 files changed, 5 insertions(+), 7 deletions(-) Please rebase onto qemu.git/master. done. I sent to qemu-trivial this time. :) -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH] target-mips: Use EXCP_SC rather than a magic number
Hi Li,
Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw
---
target-mips/op_helper.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/target-mips/op_helper.c b/target-mips/op_helper.c
index f45d494..98a445c 100644
--- a/target-mips/op_helper.c
+++ b/target-mips/op_helper.c
@@ -39,10 +39,10 @@ static inline void QEMU_NORETURN
do_raise_exception_err(CPUMIPSState *env,
uintptr_t pc)
{
TranslationBlock *tb;
-#if 1
-if (exception 0x100)
+if (exception EXCP_SC) {
qemu_log(%s: %d %d\n, __func__, exception, error_code);
-#endif
+}
+
seems original '#if 1, #endif' statement
is for temporary debug only,
so maybe can be concealed out entirely.
for log purpose, every exception code
will log when 'do_interrupt' for MIPS
if log is enabled.
Thanks for your feedback. You mean the code snippet below?
--- target-mips/helper.c
void do_interrupt (CPUMIPSState *env)
{
...
if (qemu_log_enabled() env-exception_index != EXCP_EXT_INTERRUPT) {
if (env-exception_index 0 || env-exception_index EXCP_LAST)
name = unknown;
else
name = excp_names[env-exception_index];
qemu_log(%s enter: PC TARGET_FMT_lx EPC TARGET_FMT_lx %s
exception\n,
__func__, env-active_tc.PC, env-CP0_EPC, name);
}
...
}
Maybe we can do this way?
---
diff --git a/target-mips/cpu.h b/target-mips/cpu.h
index 31602ac..507a213 100644
--- a/target-mips/cpu.h
+++ b/target-mips/cpu.h
@@ -616,9 +616,9 @@ enum {
EXCP_DSPDIS,
EXCP_LAST = EXCP_DSPDIS,
+/* Dummy exception for conditional stores. */
+EXCP_SC = EXCP_LAST,
};
-/* Dummy exception for conditional stores. */
-#define EXCP_SC 0x100
/*
* This is an interrnally generated WAKE request line.
---
Aurelien, Johnson, thoughts? :)
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] Is there anyone kindly help me to create a qemu wiki account?
On Thu, Dec 13, 2012 at 08:22:06PM +0800, Pan Xueshu wrote: Because it has been disabled to create account on the wiki page. Thanks very much! From IRC, I guess kwolf already did this for you? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH 1/3] Fix my email address
On Wed, Dec 12, 2012 at 11:02:59PM +0100, Stefan Weil wrote: Am 12.12.2012 08:24, schrieb Dongxue Zhang: Sorry I don't really catch your idea. This email address is wrong and i just want to correct it. I just want to do something to qemu. When I add target-mips/dsp_helper.c I got lots of help from other people, so I also want to help others who need help from me. But with a wrong email, they send mail to me will never get reply, this will make me looks like a cold guy, It's not what I want. So I want to correct my email address. :) Of course fixing a wrong email address is better than keeping a wrong address in the code. But will you also fix the address when you change it some day, maybe years later? What about old versions of QEMU? They will still show an old email address. Most email addresses have a limit life time. Well... Just let him fix his mail address (he want it in the source code). Maybe we can discuss if we want the mail address in the code while reviewing new coming patch next time. ;) Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] Some patch about mips, gen_HILO bug fix.
Hi, 1: Fix my email address in dsp_helper.c 2: Fix repl_ph, value should sign-extend to target_long 3: Fix gen_HILO, there is a bug when we use dsp arch, at that time acc index will be 0-3, and mipsdsp already add in. mipsdsp just take acc index from opcode, on other arch, it my bring a error. Why not use `git send-mail`? See more details on http://wiki.qemu.org/Contribute/SubmitAPatch Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH v2] exec.c: Use tb1-phys_hash_next directly in tb_remove
[CC'ed qemu-trivial]
ping?
On Wed, Nov 21, 2012 at 07:52:48AM +0800, 陳韋任 (Wei-Ren Chen) wrote:
When tb_remove was first commited at fd6ce8f6, there were three different
calls pass different names to offsetof. In current codebase, the other two
calls are replaced with tb_page_remove. There is no need to have a general
tb_remove. Omit passing the third parameter and using tb1-phys_hash_next
directly.
Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw
---
v2: Address Peter's comment.
- place comment used belong tb_remove above tb_phys_invalidate.
- remove unnecessary bracket.
exec.c | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/exec.c b/exec.c
index 8435de0..6343838 100644
--- a/exec.c
+++ b/exec.c
@@ -862,18 +862,16 @@ static void tb_page_check(void)
#endif
-/* invalidate one TB */
-static inline void tb_remove(TranslationBlock **ptb, TranslationBlock *tb,
- int next_offset)
+static inline void tb_hash_remove(TranslationBlock **ptb, TranslationBlock
*tb)
{
TranslationBlock *tb1;
for(;;) {
tb1 = *ptb;
if (tb1 == tb) {
-*ptb = *(TranslationBlock **)((char *)tb1 + next_offset);
+*ptb = tb1-phys_hash_next;
break;
}
-ptb = (TranslationBlock **)((char *)tb1 + next_offset);
+ptb = tb1-phys_hash_next;
}
}
@@ -929,6 +927,7 @@ static inline void tb_reset_jump(TranslationBlock *tb,
int n)
tb_set_jmp_target(tb, n, (uintptr_t)(tb-tc_ptr +
tb-tb_next_offset[n]));
}
+/* invalidate one TB */
void tb_phys_invalidate(TranslationBlock *tb, tb_page_addr_t page_addr)
{
CPUArchState *env;
@@ -940,8 +939,7 @@ void tb_phys_invalidate(TranslationBlock *tb,
tb_page_addr_t page_addr)
/* remove the TB from the hash list */
phys_pc = tb-page_addr[0] + (tb-pc ~TARGET_PAGE_MASK);
h = tb_phys_hash_func(phys_pc);
-tb_remove(tb_phys_hash[h], tb,
- offsetof(TranslationBlock, phys_hash_next));
+tb_hash_remove(tb_phys_hash[h], tb);
/* remove the TB from the page list */
if (tb-page_addr[0] != page_addr) {
--
1.7.3.4
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH_v3] add target-openrisc floating point exception
Hi Feng,
One question,
@@ -25,5 +25,5 @@ void HELPER(exception)(CPUOpenRISCState *env,
uint32_t excp)
{
OpenRISCCPU *cpu = OPENRISC_CPU(ENV_GET_CPU(env));
-raise_exception(cpu, excp);
+do_raise_exception(cpu, excp, 0);
}
Shouldn't above helper function be called from the code cache?
The 3rd argument of do_raise_exception means if the exception comes
from code cache or not, iiuc. Is it correct to put zero here?
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH] tcg-i386: Improve cmov detection
On Mon, Nov 26, 2012 at 08:23:10AM -0800, Richard Henderson wrote: On 11/24/2012 10:12 AM, Peter Maydell wrote: MacOS gcc objects to this: In file included from /Users/pm215/src/qemu/tcg/tcg.c:174: /Users/pm215/src/qemu/tcg/i386/tcg-target.c:105:19: warning: cpuid.h: No such file or directory (though for some reason not as a fatal error). Bizzare. Out of curiosity, does llvm ship a cpuid.h? Or am I going to be better off not relying on that header at all? I don't think LLVM ship cpuid.h. -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
[Qemu-devel] [PATCH] target-mips: Use EXCP_SC rather than a magic number
From the discussion on the ML [1], the exception limit defined by
magic number 0x100 is actually EXCP_SC defined in cpu.h. Replace the
magic number with EXCP_SC. Remove #if 1 .. #endif as well.
[1] http://lists.gnu.org/archive/html/qemu-devel/2012-11/msg03080.html
Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw
---
target-mips/op_helper.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/target-mips/op_helper.c b/target-mips/op_helper.c
index f45d494..98a445c 100644
--- a/target-mips/op_helper.c
+++ b/target-mips/op_helper.c
@@ -39,10 +39,10 @@ static inline void QEMU_NORETURN
do_raise_exception_err(CPUMIPSState *env,
uintptr_t pc)
{
TranslationBlock *tb;
-#if 1
-if (exception 0x100)
+if (exception EXCP_SC) {
qemu_log(%s: %d %d\n, __func__, exception, error_code);
-#endif
+}
+
env-exception_index = exception;
env-error_code = error_code;
--
1.7.3.4
Re: [Qemu-devel] [PATCH 3/3] target-i386:slightly refactor dr7 related function
On Thu, Dec 06, 2012 at 05:27:44PM +0800, li guang wrote:
在 2012-12-06四的 09:23 +，Peter Maydell写道：
On 6 December 2012 09:16, li guang lig.f...@cn.fujitsu.com wrote:
在 2012-12-06四的 08:54 +，Peter Maydell写道：
On 6 December 2012 03:03, liguang lig.f...@cn.fujitsu.com wrote:
Signed-off-by: liguang lig.f...@cn.fujitsu.com
--- a/target-i386/seg_helper.c
+++ b/target-i386/seg_helper.c
@@ -465,9 +465,9 @@ static void switch_tss(CPUX86State *env, int
tss_selector,
#ifndef CONFIG_USER_ONLY
/* reset local breakpoints */
-if (env-dr[7] 0x55) {
-for (i = 0; i 4; i++) {
-if (hw_breakpoint_enabled(env-dr[7], i) == 0x1) {
+if (env-dr[7] DR7_LOCAL_BP_MASK) {
+for (i = 0; i DR7_MAX_BP; i++) {
+if (hw_breakpoint_enabled(env-dr[7], i)) {
hw_breakpoint_remove(env, i);
}
}
This is still wrong.
do you mean the use of 'hw_breakpoint_enabled'? or others?
maybe a mistake, I change it to 'hw_local_breakpoint_enabled'.
if it is I'll re-send a corrected patch.
I mean that in the comments on the previous version of this
patchseet we explained that this check is specifically checking
for whether the breakpoint is enabled locally, and that your
change to just returning bool broke this. And in this version
of the patch there is still exactly the same problem.
why broke?
this function just ask if breakpoint 'i' was enable,
so we answer enabled or not? 2 simple cases, any problem?
I don't read this patch from the starting. But Peter, do you mean
the return value matters here? I see the original version compares
the return value with 0x1, do you mean we *need* this comparsion here?
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH] Modified OpenRisc fpu exception
-void QEMU_NORETURN raise_exception(OpenRISCCPU *cpu, uint32_t excp)
+void QEMU_NORETURN do_raise_exception_err(OpenRISCCPU *cpu,
+ uint32_t exception,
+ uintptr_t pc)
{
-cpu-env.exception_index = excp;
+TranslationBlock *tb;
+
+/* openrisc cpu has fifteen exceptions */
+if (exception 0xe)
+qemu_log(%s: %d\n, __func__, exception);
+
+cpu-env.exception_index = exception;
+
+if (pc) {
+/* now we have a real cpu fault */
+tb = tb_find_pc(pc);
+if (tb) {
+/* the PC is inside the translated code. It means that we have
+ a virtual CPU fault */
+cpu_restore_state(tb, cpu-env, pc);
+}
+}
+
cpu_loop_exit(cpu-env);
}
+
+void QEMU_NORETURN do_raise_exception(OpenRISCCPU *cpu,
+ uint32_t exception,
+ uintptr_t pc)
+{
+do_raise_exception_err(cpu, exception, pc);
+}
Please change your subject into [PATCH v2] ... so that others will
notice this is a new version patch. See [1] for more detail. Also, you
still doesn't address v1's comment. Why you put both do_raise_exception_err
and do_raise_exception here? It's unnecessary to me.
Regards,
chenwj
[1] http://wiki.qemu.org/Contribute/SubmitAPatch
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH 1.3] build: compile translate.o at -O1 optimization
On Tue, Nov 27, 2012 at 02:45:07PM +0100, Gerd Hoffmann wrote: On 11/27/12 14:24, Peter Maydell wrote: On 27 November 2012 08:34, Paolo Bonzini pbonz...@redhat.com wrote: Some versions of GCC require insane (2GB) amounts of memory to compile translate.o. As a countermeasure, compile it with -O1. This should fix the buildbot failure for default_x86_64_fedora16. This is a well known bug in old gcc (ie fixed in 4.5, 4.6 and trunk a year ago). Use a newer gcc, or a 64 bit build system with a reasonable amount of RAM, or as a workaround apply some suitable compiler flags by passing configure '--extra-cflags=-fno-var-tracking'. This patch definitely shouldn't be applied as we shouldn't be hampering the majority for the benefit of old broken systems. It isn't that simple. It's Fedora 17 with gcc 4.7.2 which runs oom while compiling translate.c Even apply Peter's suggestion? Do all gcc 4.7.2 on various platform have the same problem, or it only happen on Fedora 17. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH v2 1.3] build: compile translate.o with -fno-gcse option
On Tue, Nov 27, 2012 at 05:21:03PM +0100, Paolo Bonzini wrote: Some versions of GCC require insane (2GB) amounts of memory to compile translate.o. As a countermeasure, disable the culprit optimization pass. This should fix the buildbot failure for default_x86_64_fedora16. Anyway is a good thing to do because people will try to compile 1.3 with less than 2GB of memory and complain. Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile.target | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Makefile.target b/Makefile.target index 8b658c0..d38bb58 100644 --- a/Makefile.target +++ b/Makefile.target @@ -143,6 +143,12 @@ GENERATED_HEADERS += hmp-commands.h qmp-commands-old.h endif # CONFIG_SOFTMMU +# Workaround for http://gcc.gnu.org/PR55489. Happens with -fPIE/-fPIC +# and large functions that use global variables. The bug is in all +# releases of GCC, but it became particularly acute in 4.7.x. We +# should be able to delete this at the end of 2013. +%/translate.o: QEMU_CFLAGS += -fno-gcse + nested-vars += obj-y # This resolves all nested paths, so it must come last No objection here. But will we remove this option when GCC fix this pr or we just leave it there? If we're going to remove it in the future, better keep a note on the release change log or somewhere else. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH] exec.c: Use tb1-phys_hash_next directly in tb_remove
On Sun, Nov 25, 2012 at 10:47:00AM +, Peter Maydell wrote: On 25 November 2012 07:50, 陳韋任 (Wei-Ren Chen) che...@iis.sinica.edu.tw wrote: ping? This is v1 of the patch, you've sent a v2 and should be pinging that instead... Also (a) it won't go in before 1.3 release now so not much point in being too eager with the pings (b) you could cc qemu-trivial. Got it. ;) -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH] exec.c: Use tb1-phys_hash_next directly in tb_remove
ping?
On Tue, Nov 20, 2012 at 12:41:03PM +, Peter Maydell wrote:
On 20 November 2012 12:30, 陳韋任 (Wei-Ren Chen) che...@iis.sinica.edu.tw
wrote:
When tb_remove was first commited at fd6ce8f6, there were three different
calls pass different names to offsetof. In current codebase, the other two
calls are replaced with tb_page_remove. There is no need to have a general
tb_remove. Omit passing the third parameter and using tb1-phys_hash_next
directly.
I like this, it makes the function less confusing to remove this
now-unneeded generality.
Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw
---
exec.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/exec.c b/exec.c
index 8435de0..e54fce2 100644
--- a/exec.c
+++ b/exec.c
@@ -863,17 +863,16 @@ static void tb_page_check(void)
#endif
/* invalidate one TB */
This comment is now a bit out of date (and in fact it has been for
some time) and should probably be deleted. (The function that really
needs a comment is the top level tb_phys_invalidate(), rather than
the helpers tb_hash_remove/tb_page_remove/tb_jmp_remove.)
-static inline void tb_remove(TranslationBlock **ptb, TranslationBlock *tb,
- int next_offset)
+static inline void tb_hash_remove(TranslationBlock **ptb, TranslationBlock
*tb)
{
TranslationBlock *tb1;
for(;;) {
tb1 = *ptb;
if (tb1 == tb) {
-*ptb = *(TranslationBlock **)((char *)tb1 + next_offset);
+*ptb = tb1-phys_hash_next;
break;
}
-ptb = (TranslationBlock **)((char *)tb1 + next_offset);
+ptb = (tb1-phys_hash_next);
You don't need these brackets.
}
}
@@ -940,8 +939,7 @@ void tb_phys_invalidate(TranslationBlock *tb,
tb_page_addr_t page_addr)
/* remove the TB from the hash list */
phys_pc = tb-page_addr[0] + (tb-pc ~TARGET_PAGE_MASK);
h = tb_phys_hash_func(phys_pc);
-tb_remove(tb_phys_hash[h], tb,
- offsetof(TranslationBlock, phys_hash_next));
+tb_hash_remove(tb_phys_hash[h], tb);
/* remove the TB from the page list */
if (tb-page_addr[0] != page_addr) {
--
1.7.3.4
-- PMM
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] FYI: KVM Forum community team photo
On Thu, Nov 22, 2012 at 10:40:11AM +, Daniel P. Berrange wrote: At the LinuxCon / KVM Forum last week, a bunch of QEMU/KVM community members were rounded up to pose for a team photo. Thanks to Jeff Cody who was the one with the camera. I've put the photo up here along with, what I hope is a correct, list of names against faces... http://www.linux-kvm.org/static/kvm-forum-2012-barcelona-team-photo.html Great! -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH] target-or32: Improve float exception
-void QEMU_NORETURN raise_exception(OpenRISCCPU *cpu, uint32_t excp)
+void QEMU_NORETURN raise_exception(OpenRISCCPU *cpu, uint32_t exception)
{
-cpu-env.exception_index = excp;
+do_raise_exception_err(cpu, exception, 0);
+}
+
+void QEMU_NORETURN do_raise_exception_err(OpenRISCCPU *cpu,
+ uint32_t exception,
+ uintptr_t pc)
+{
+TranslationBlock *tb;
+#if 1
+if (exception 0x100)
+qemu_log(%s: %d\n, __func__, exception);
+#endif
+cpu-env.exception_index = exception;
+
+if (pc) {
+/* now we have a real cpu fault */
+tb = tb_find_pc(pc);
+if (tb) {
+/* the PC is inside the translated code. It means that we have
+ a virtual CPU fault */
+cpu_restore_state(tb, cpu-env, pc);
+}
+}
+
cpu_loop_exit(cpu-env);
}
+
+void QEMU_NORETURN do_raise_exception(OpenRISCCPU *cpu,
+ uint32_t exception,
+ uintptr_t pc)
+{
+do_raise_exception_err(cpu, exception, pc);
+}
I don't see any difference between do_raise_exception_err and
do_raise_exception here. MIPS do have those functions, but function
do_raise_exception_err has one more parameter for error code.
Please see target-mips/op_helper.c. If you don't need error code,
there just one function would be sufficient, I think.
diff --git a/target-openrisc/exception.h b/target-openrisc/exception.h
index 4b64430..1f0cd90 100644
--- a/target-openrisc/exception.h
+++ b/target-openrisc/exception.h
@@ -23,6 +23,12 @@
#include cpu.h
#include qemu-common.h
-void QEMU_NORETURN raise_exception(OpenRISCCPU *cpu, uint32_t excp);
+void QEMU_NORETURN raise_exception(OpenRISCCPU *cpu, uint32_t exception);
+void QEMU_NORETURN do_raise_exception_err(OpenRISCCPU *cpu,
+ uint32_t exception,
+ uintptr_t pc);
+void QEMU_NORETURN do_raise_exception(OpenRISCCPU *cpu,
+ uint32_t exception,
+ uintptr_t pc);
Ditto.
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH] target-or32: Improve float exception
+void QEMU_NORETURN do_raise_exception_err(OpenRISCCPU *cpu,
+ uint32_t exception,
+ uintptr_t pc)
+{
+TranslationBlock *tb;
+#if 1
+if (exception 0x100)
+qemu_log(%s: %d\n, __func__, exception);
+#endif
Stray debug tracing?
target-mips/op_helper.c also has such #if 1 .. #endif.
Should we remove it?
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
[Qemu-devel] MIPS exception number limits?
Hi all,
Wondering why MIPS limits exception number less then 0x100,
you can see such example in function do_raise_exception_err
(target-mips/op_helper.c). See below,
static inline void QEMU_NORETURN do_raise_exception_err(CPUMIPSState *env,
...
{
...
#if 1
if (exception 0x100)
qemu_log(%s: %d %d\n, __func__, exception, error_code);
#endif
...
}
Anyone can help confirm this, stated in what spec? Also, do we
need #if 1 .. #endif? Thanks for help. =]
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH v2] target-mips: Clean up microMIPS32 major opcode
ping? -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
[Qemu-devel] [PATCH] exec.c: Use tb1-phys_hash_next directly in tb_remove
When tb_remove was first commited at fd6ce8f6, there were three different
calls pass different names to offsetof. In current codebase, the other two
calls are replaced with tb_page_remove. There is no need to have a general
tb_remove. Omit passing the third parameter and using tb1-phys_hash_next
directly.
Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw
---
exec.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/exec.c b/exec.c
index 8435de0..e54fce2 100644
--- a/exec.c
+++ b/exec.c
@@ -863,17 +863,16 @@ static void tb_page_check(void)
#endif
/* invalidate one TB */
-static inline void tb_remove(TranslationBlock **ptb, TranslationBlock *tb,
- int next_offset)
+static inline void tb_hash_remove(TranslationBlock **ptb, TranslationBlock *tb)
{
TranslationBlock *tb1;
for(;;) {
tb1 = *ptb;
if (tb1 == tb) {
-*ptb = *(TranslationBlock **)((char *)tb1 + next_offset);
+*ptb = tb1-phys_hash_next;
break;
}
-ptb = (TranslationBlock **)((char *)tb1 + next_offset);
+ptb = (tb1-phys_hash_next);
}
}
@@ -940,8 +939,7 @@ void tb_phys_invalidate(TranslationBlock *tb,
tb_page_addr_t page_addr)
/* remove the TB from the hash list */
phys_pc = tb-page_addr[0] + (tb-pc ~TARGET_PAGE_MASK);
h = tb_phys_hash_func(phys_pc);
-tb_remove(tb_phys_hash[h], tb,
- offsetof(TranslationBlock, phys_hash_next));
+tb_hash_remove(tb_phys_hash[h], tb);
/* remove the TB from the page list */
if (tb-page_addr[0] != page_addr) {
--
1.7.3.4
[Qemu-devel] [PATCH v2] exec.c: Use tb1-phys_hash_next directly in tb_remove
When tb_remove was first commited at fd6ce8f6, there were three different
calls pass different names to offsetof. In current codebase, the other two
calls are replaced with tb_page_remove. There is no need to have a general
tb_remove. Omit passing the third parameter and using tb1-phys_hash_next
directly.
Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw
---
v2: Address Peter's comment.
- place comment used belong tb_remove above tb_phys_invalidate.
- remove unnecessary bracket.
exec.c | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/exec.c b/exec.c
index 8435de0..6343838 100644
--- a/exec.c
+++ b/exec.c
@@ -862,18 +862,16 @@ static void tb_page_check(void)
#endif
-/* invalidate one TB */
-static inline void tb_remove(TranslationBlock **ptb, TranslationBlock *tb,
- int next_offset)
+static inline void tb_hash_remove(TranslationBlock **ptb, TranslationBlock *tb)
{
TranslationBlock *tb1;
for(;;) {
tb1 = *ptb;
if (tb1 == tb) {
-*ptb = *(TranslationBlock **)((char *)tb1 + next_offset);
+*ptb = tb1-phys_hash_next;
break;
}
-ptb = (TranslationBlock **)((char *)tb1 + next_offset);
+ptb = tb1-phys_hash_next;
}
}
@@ -929,6 +927,7 @@ static inline void tb_reset_jump(TranslationBlock *tb, int
n)
tb_set_jmp_target(tb, n, (uintptr_t)(tb-tc_ptr + tb-tb_next_offset[n]));
}
+/* invalidate one TB */
void tb_phys_invalidate(TranslationBlock *tb, tb_page_addr_t page_addr)
{
CPUArchState *env;
@@ -940,8 +939,7 @@ void tb_phys_invalidate(TranslationBlock *tb,
tb_page_addr_t page_addr)
/* remove the TB from the hash list */
phys_pc = tb-page_addr[0] + (tb-pc ~TARGET_PAGE_MASK);
h = tb_phys_hash_func(phys_pc);
-tb_remove(tb_phys_hash[h], tb,
- offsetof(TranslationBlock, phys_hash_next));
+tb_hash_remove(tb_phys_hash[h], tb);
/* remove the TB from the page list */
if (tb-page_addr[0] != page_addr) {
--
1.7.3.4
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
[Qemu-devel] [PATCH v2] target-mips: Add comments on POOL32Axf encoding
Current QEMU MIPS POOL32AXF encoding comes from microMIPS32
and microMIPS32 DSP. Add comment here to help reading.
Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw
---
v2: Correct commit message formatting
target-mips/translate.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index 8b438f8..e453d9e 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -10359,6 +10359,19 @@ enum {
/* POOL32AXF encoding of minor opcode field extension */
+/*
+ * 1. MIPS Architecture for Programmers Volume II-B:
+ * The microMIPS32 Instruction Set (Revision 3.05)
+ *
+ *Table 6.5 POOL32Axf Encoding of Minor Opcode Extension Field
+ *
+ * 2. MIPS Architecture for Programmers VolumeIV-e:
+ * The MIPS DSP Application-Specific Extension
+ *to the microMIPS32 Architecture (Revision 2.34)
+ *
+ *Table 5.5 POOL32Axf Encoding of Minor Opcode Extension Field
+ */
+
enum {
/* bits 11..6 */
TEQ = 0x00,
@@ -10371,6 +10384,8 @@ enum {
MFC0 = 0x03,
MTC0 = 0x0b,
+/* begin of microMIPS32 DSP */
+
/* bits 13..12 for 0x01 */
MFHI_ACC = 0x0,
MFLO_ACC = 0x1,
@@ -10387,6 +10402,8 @@ enum {
MULT_ACC = 0x0,
MULTU_ACC = 0x1,
+/* end of microMIPS32 DSP */
+
/* bits 15..12 for 0x2c */
SEB = 0x2,
SEH = 0x3,
--
1.7.12.3
Re: [Qemu-devel] [PATCH] target-mips: Add comments on POOL32Axf encoding
Hi Johnson, My bad. Will resend pacth later. ;) Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
[Qemu-devel] [PATCH v3] target-mips: Clean up microMIPS32 major opcode
I check MIPS microMIPS manual [1], and found the major opcode might
be wrong. I add a comment to explicitly indicate what manual I am refering
to, and according that manual I remove microMIPS32 major opcodes 0x1f.
As for others, like 0x16, 0x17, 0x36 and 0x37, they are for higher-order
MIPS ISA level or new revision of this microMIPS architecture. Quote
from Johnson, they are belong MIPS64 [2].
[1] http://www.mips.com/products/architectures/micromips/#specifications
MIPS Architecture for Programmers Volume II-B:
The microMIPS32 Instruction Set (Revision 3.05)
MD00582-2B-microMIPS-AFP-03.05.pdf
[2] http://www.mips.com/products/architectures/mips64/
MIPS Architecture For Programmers
Volume II-A: The MIPS64 Instruction Set
MD00087-2B-MIPS64BIS-AFP-03.51.pdf
Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw
---
v3: Correct commit message formatting.
v2: Remove POOL48A only. The other three opcode are belong MIPS64.
target-mips/translate.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index 8b438f8..7fe8d83 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -10239,9 +10239,19 @@ static int decode_mips16_opc (CPUMIPSState *env,
DisasContext *ctx,
return n_bytes;
}
-/* microMIPS extension to MIPS32 */
+/* microMIPS extension to MIPS32/MIPS64 */
-/* microMIPS32 major opcodes */
+/*
+ * microMIPS32/microMIPS64 major opcodes
+ *
+ * 1. MIPS Architecture for Programmers Volume II-B:
+ * The microMIPS32 Instruction Set (Revision 3.05)
+ *
+ *Table 6.2 microMIPS32 Encoding of Major Opcode Field
+ *
+ * 2. MIPS Architecture For Programmers Volume II-A:
+ * The MIPS64 Instruction Set (Revision 3.51)
+ */
enum {
POOL32A = 0x00,
@@ -10268,9 +10278,10 @@ enum {
POOL16D = 0x13,
ORI32 = 0x14,
POOL32F = 0x15,
-POOL32S = 0x16,
-DADDIU32 = 0x17,
+POOL32S = 0x16, /* MIPS64 */
+DADDIU32 = 0x17, /* MIPS64 */
+/* 0x1f is reserved */
POOL32C = 0x18,
LWGP16 = 0x19,
LW16 = 0x1a,
@@ -10278,7 +10289,6 @@ enum {
XORI32 = 0x1c,
JALS32 = 0x1d,
ADDIUPC = 0x1e,
-POOL48A = 0x1f,
/* 0x20 is reserved */
RES_20 = 0x20,
@@ -10307,8 +10317,8 @@ enum {
B16 = 0x33,
ANDI32 = 0x34,
J32 = 0x35,
-SD32 = 0x36,
-LD32 = 0x37,
+SD32 = 0x36, /* MIPS64 */
+LD32 = 0x37, /* MIPS64 */
/* 0x38 and 0x39 are reserved */
RES_38 = 0x38,
--
1.7.12.3
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH] target-mips: Add comments on POOL32Axf encoding
ping?
On Fri, Nov 16, 2012 at 10:29:47AM +0800, 陳韋任 (Wei-Ren Chen) wrote:
Hi all,
Current QEMU MIPS POOL32AXF encoding comes from microMIPS32
and microMIPS32 DSP. Add comment here to help reading.
Please review, thanks.
Regards,
chenwj
Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw
---
target-mips/translate.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index 01b48fa..9d4b2c3 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -10359,6 +10359,19 @@ enum {
/* POOL32AXF encoding of minor opcode field extension */
+/*
+ * 1. MIPS Architecture for Programmers Volume II-B:
+ * The microMIPS32 Instruction Set (Revision 3.05)
+ *
+ * Table 6.5 POOL32Axf Encoding of Minor Opcode Extension Field
+ *
+ * 2. MIPS Architecture for Programmers VolumeIV-e:
+ * The MIPS DSP Application-Specific Extension
+ * to the microMIPS32 Architecture (Revision 2.34)
+ *
+ * Table 5.5 POOL32Axf Encoding of Minor Opcode Extension Field
+ */
+
enum {
/* bits 11..6 */
TEQ = 0x00,
@@ -10371,6 +10384,8 @@ enum {
MFC0 = 0x03,
MTC0 = 0x0b,
+/* begin of microMIPS32 DSP */
+
/* bits 13..12 for 0x01 */
MFHI_ACC = 0x0,
MFLO_ACC = 0x1,
@@ -10387,6 +10402,8 @@ enum {
MULT_ACC = 0x0,
MULTU_ACC = 0x1,
+/* end of microMIPS32 DSP */
+
/* bits 15..12 for 0x2c */
SEB = 0x2,
SEH = 0x3,
--
1.7.3.4
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [Qemu-trivial] [PATCH v2] target-mips: Clean up microMIPS32 major opcode
Please send this through Aurelian as maintainer for target-mips/. The discussion on previous the thread show this isn't qemu-trivial material :). O.K., I'll remove this from qemu-trivial if I need to send revision next time. Thanks, Stefan. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [Qemu-trivial] [PATCH] target-mips: Add comments on POOL32Axf encoding
On Fri, Nov 16, 2012 at 02:59:30PM +0100, Stefan Hajnoczi wrote: On Fri, Nov 16, 2012 at 10:29:47AM +0800, 陳韋任 (Wei-Ren Chen) wrote: Current QEMU MIPS POOL32AXF encoding comes from microMIPS32 and microMIPS32 DSP. Add comment here to help reading. Please review, thanks. Regards, chenwj Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw --- target-mips/translate.c | 17 + 1 files changed, 17 insertions(+), 0 deletions(-) Please send this through Aurelien. Perhaps there's more to discuss about how the various MIPS instruction sets should be organized in QEMU. Got it. ;) -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
[Qemu-devel] Question about comment on MIPS POOL32AXF encoding
Hi all, I am reading POOL32AXF encoding in target-mips/translate.c, and can't understand what the comment says. For example, /* bits 13..12 for 0x01 */ MFHI_ACC = 0x0, MFLO_ACC = 0x1, MTHI_ACC = 0x2, MTLO_ACC = 0x3, I compare this with microMIPS32 manual [1] Table 6.5, but I still don't understand why they're encoded in such way. The comment says bits 13..12 for 0x01, I can roughly understand the enum list bits 13..12 here, but what for 0x01 exactly means? Thanks. Regards, chenwj [1] MIPS Architecture for Programmers Volume II-B: The microMIPS32 Instruction Set -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
[Qemu-devel] [PATCH v2] target-mips: Clean up microMIPS32 major opcode
Hi all,
I check MIPS microMIPS manual [1], and found the major opcode might be
wrong. I add a comment to explicitly indicate what manual I am refering
to, and according that manual I remove microMIPS32 major opcodes 0x1f.
As for others, like 0x16, 0x17, 0x36 and 0x37, they are for higher-order
MIPS ISA level or new revision of this microMIPS architecture. Quote
from Johnson, they are belong MIPS64 [2].
Please review, thanks.
[1] http://www.mips.com/products/architectures/micromips/#specifications
MIPS Architecture for Programmers Volume II-B:
The microMIPS32 Instruction Set (Revision 3.05)
MD00582-2B-microMIPS-AFP-03.05.pdf
[2] http://www.mips.com/products/architectures/mips64/
MIPS Architecture For Programmers
Volume II-A: The MIPS64 Instruction Set
MD00087-2B-MIPS64BIS-AFP-03.51.pdf
Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw
---
target-mips/translate.c | 24 +---
1 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index 01b48fa..1c0ff65 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -10239,9 +10239,19 @@ static int decode_mips16_opc (CPUMIPSState *env,
DisasContext *ctx,
return n_bytes;
}
-/* microMIPS extension to MIPS32 */
+/* microMIPS extension to MIPS32/MIPS64 */
-/* microMIPS32 major opcodes */
+/*
+ * microMIPS32/microMIPS64 major opcodes
+ *
+ * 1. MIPS Architecture for Programmers Volume II-B:
+ * The microMIPS32 Instruction Set (Revision 3.05)
+ *
+ * Table 6.2 microMIPS32 Encoding of Major Opcode Field
+ *
+ * 2. MIPS Architecture For Programmers Volume II-A:
+ * The MIPS64 Instruction Set (Revision 3.51)
+ */
enum {
POOL32A = 0x00,
@@ -10268,9 +10278,10 @@ enum {
POOL16D = 0x13,
ORI32 = 0x14,
POOL32F = 0x15,
-POOL32S = 0x16,
-DADDIU32 = 0x17,
+POOL32S = 0x16, /* MIPS64 */
+DADDIU32 = 0x17, /* MIPS64 */
+/* 0x1f is reserved */
POOL32C = 0x18,
LWGP16 = 0x19,
LW16 = 0x1a,
@@ -10278,7 +10289,6 @@ enum {
XORI32 = 0x1c,
JALS32 = 0x1d,
ADDIUPC = 0x1e,
-POOL48A = 0x1f,
/* 0x20 is reserved */
RES_20 = 0x20,
@@ -10307,8 +10317,8 @@ enum {
B16 = 0x33,
ANDI32 = 0x34,
J32 = 0x35,
-SD32 = 0x36,
-LD32 = 0x37,
+SD32 = 0x36, /* MIPS64 */
+LD32 = 0x37, /* MPIS64 */
/* 0x38 and 0x39 are reserved */
RES_38 = 0x38,
--
1.7.3.4
Re: [Qemu-devel] Question about comment on MIPS POOL32AXF encoding
Please refer to the following document. MIPS® Architecture for Programmers VolumeIV-e: The MIPS® DSP Application-Specific Extension to the microMIPS32™ Architecture http://www.mips.com/secure-download/index.dot?product_name=/auth/MD00764-2B-microMIPS32DSP-AFP-02.34.pdf Thanks, Eric. I would like to add a comment here to remind me where they come. :) Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
[Qemu-devel] [PATCH] target-mips: Add comments on POOL32Axf encoding
Hi all,
Current QEMU MIPS POOL32AXF encoding comes from microMIPS32
and microMIPS32 DSP. Add comment here to help reading.
Please review, thanks.
Regards,
chenwj
Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw
---
target-mips/translate.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index 01b48fa..9d4b2c3 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -10359,6 +10359,19 @@ enum {
/* POOL32AXF encoding of minor opcode field extension */
+/*
+ * 1. MIPS Architecture for Programmers Volume II-B:
+ * The microMIPS32 Instruction Set (Revision 3.05)
+ *
+ * Table 6.5 POOL32Axf Encoding of Minor Opcode Extension Field
+ *
+ * 2. MIPS Architecture for Programmers VolumeIV-e:
+ * The MIPS DSP Application-Specific Extension
+ * to the microMIPS32 Architecture (Revision 2.34)
+ *
+ * Table 5.5 POOL32Axf Encoding of Minor Opcode Extension Field
+ */
+
enum {
/* bits 11..6 */
TEQ = 0x00,
@@ -10371,6 +10384,8 @@ enum {
MFC0 = 0x03,
MTC0 = 0x0b,
+/* begin of microMIPS32 DSP */
+
/* bits 13..12 for 0x01 */
MFHI_ACC = 0x0,
MFLO_ACC = 0x1,
@@ -10387,6 +10402,8 @@ enum {
MULT_ACC = 0x0,
MULTU_ACC = 0x1,
+/* end of microMIPS32 DSP */
+
/* bits 15..12 for 0x2c */
SEB = 0x2,
SEH = 0x3,
--
1.7.3.4
[Qemu-devel] [PATCH] target-mips: Clean up microMIPS32 major opcode
Hi all,
I check MIPS microMIPS manual [1], and found the major opcode might be
wrong. I add a comment to explicitly indicate what manual I am refering
to, and according that manual I remove some microMIPS32 major opcodes.
Major opcode 0x1f is reserved, so I just remove it. As for others, like
0x16, 0x17, 0x36 and 0x37, they are for higher-order MIPS ISA level or
new revision of this microMIPS architecture. Since they are not appear
in the manual I refer to, I just remove them as well.
Please review, thanks.
[1] http://www.mips.com/products/architectures/micromips/#specifications
MIPS Architecture for Programmers Volume II-B:
The microMIPS32 Instruction Set (Revision 3.05)
MD00582-2B-microMIPS-AFP-03.05.pdf
Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw
---
target-mips/translate.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index f6fc0c2..b57da24 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -10241,7 +10241,15 @@ static int decode_mips16_opc (CPUMIPSState *env,
DisasContext *ctx,
/* microMIPS extension to MIPS32 */
-/* microMIPS32 major opcodes */
+/*
+ * microMIPS32 major opcodes
+ *
+ * MIPS Architecture for Programmers Volume II-B:
+ * The microMIPS32 Instruction Set (Revision 3.05)
+ *
+ * Table 6.2 microMIPS32 Encoding of Major Opcode Field
+ *
+ */
enum {
POOL32A = 0x00,
@@ -10268,9 +10276,8 @@ enum {
POOL16D = 0x13,
ORI32 = 0x14,
POOL32F = 0x15,
-POOL32S = 0x16,
-DADDIU32 = 0x17,
+/* 0x1f is reserved */
POOL32C = 0x18,
LWGP16 = 0x19,
LW16 = 0x1a,
@@ -10278,7 +10285,6 @@ enum {
XORI32 = 0x1c,
JALS32 = 0x1d,
ADDIUPC = 0x1e,
-POOL48A = 0x1f,
/* 0x20 is reserved */
RES_20 = 0x20,
@@ -10307,8 +10313,6 @@ enum {
B16 = 0x33,
ANDI32 = 0x34,
J32 = 0x35,
-SD32 = 0x36,
-LD32 = 0x37,
/* 0x38 and 0x39 are reserved */
RES_38 = 0x38,
--
1.7.3.4
Re: [Qemu-devel] [PATCH] target-mips: Clean up microMIPS32 major opcode
On Thu, Nov 15, 2012 at 02:34:31AM +, Johnson, Eric wrote: Hi Chen, Please only remove the POOL48A opcode. The others are documented in the microMIPS64 Instruction Set manual ( http://www.mips.com/secure-download/index.dot?product_name=/auth/MD00087-2B-MIPS64BIS-AFP-03.51.pdf ). See http://www.mips.com/products/architectures/mips64/ for other relavent docs. Instead of removing them please surround the POOL32S, DADDIU32, SD32, and LD32 opcodes with #if defined(TARGET_MIPS64) Just want to make sure I am reading the right manual, are you refering to [1] or [2]? The link you gave me is about MIPS64 not microMIPS64, I am not sure which one I should look into. I can find DADDIU, SD, and LD in [1] and [2], all *without* 32 suffix. Should I change their name? I cannot find POOL32S in both document, would you like to point it out? Thanks. Regards, chenwj [1] MIPS Architecture For Programmers Volume I-B: Introduction to the microMIPS64 Architecture MD00743-2B-microMIPS64INT-AFP-03.02.pdf [2] MIPS Architecture For Programmers Volume II-A: The MIPS64 Instruction Set MD00087-2B-MIPS64BIS-AFP-03.51.pdf -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH] target-mips: Clean up microMIPS32 major opcode
On Thu, Nov 15, 2012 at 04:01:32AM +, Johnson, Eric wrote: Hi Chen, Sorry I must have made a copy paste error. I access the documents internally. I'll double check the link tomorrow. The document I referenced is the MIPS64 not the microMIPS64. Do not change the names. The LD32 and SD32 are microMIPS specific. The assembler LD and SD opcodes work for either MIPS64 or microMIPS64. O.K., thanks for the help. :) How about DADDIU32, should I keep the 32 suffix, too? I still can't find where POOL32S is. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH] correct error message qemu-img reported
On Fri, Nov 02, 2012 at 10:35:50AM +0800, liguang wrote:
qemu-img will complain when qcow or qcow2
size overflow for 64 bits, report the right
message in this condition.
Signed-off-by: liguang lig.f...@cn.fujitsu.com
---
qemu-img.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/qemu-img.c b/qemu-img.c
index f17f187..a332467 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -343,10 +343,12 @@ static int img_create(int argc, char **argv)
/* Get image size, if specified */
if (optind argc) {
-int64_t sval;
+int64_t sval = 0;
char *end;
sval = strtosz_suffix(argv[optind++], end, STRTOSZ_DEFSUFFIX_B);
-if (sval 0 || *end) {
+ if (sval 0)
+ error_report(image size is too large!\n);
^^^
wrong ident?
+if (*end) {
error_report(Invalid image size specified! You may use k, M, G
or
T suffixes for );
error_report(kilobytes, megabytes, gigabytes and terabytes.);
--
1.7.1
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH 0/5] register reset handlers to reload image
On Fri, Oct 26, 2012 at 04:02:01PM +0800, Olivia Yin wrote: Register reset handlers image_blob_reset and image_file_reset to reload images when virtual machine reset. This way could optimize footprint of QEMU. This is the first part of the patches which remove rom related functions in loader.c The second part will optimize memory regions which use rom_ptr. Signed-off-by: Olivia Yin hong-hua@freescale.com 0001-define-image_file_reset-and-image_blob_reset.patch 0002-use-reset-handlers-to-reload-kernel-and-initrd.patch 0003-replace-rom_add_file-with-image_file_reset.patch 0004-replaece-rom_add_blob-with-image_blob_reset.patch 0005-remove-rom-related-functions-in-loader.patch The patch format looks weird to me. Please refer to [1] to see how to send patch to QEMU ML. You should use `git format-patch` then `git send-email` to send your patchset. By deafult, `git send-mail` should thread your patch together, which means every patch in the series will be threaded to reply the first (cover) letter. Regards, chenwj [1] http://wiki.qemu.org/Contribute/SubmitAPatch -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH 1/5] define image_file_reset and image_blob_reset
+typedef struct ImageFile ImageFile;
+struct ImageFile {
+char *name;
+char *dir;
+target_phys_addr_t addr;
target_phys_addr_t has been replaced with hwaddr,
see [1].
+};
+
+typedef struct ImageBlob ImageBlob;
+struct ImageBlob {
+char *name;
+target_phys_addr_t addr;
ditto.
Regards,
chenwj
[1]
http://git.qemu.org/qemu.git/commit/?id=51ef67270b1d10e1fcf3de7368dccad1ba0bf9d1
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH 2/5] use reset handlers to reload kernel and initrd
-/* Load a U-Boot image. */ -int load_uimage(const char *filename, target_phys_addr_t *ep, -target_phys_addr_t *loadaddr, int *is_linux) +/* write uimage into memory */ +static int uimage_physical_loader(const char *filename, uint8_t **data, + target_phys_addr_t *loadaddr) ^^ Use hwaddr instead. I guess you need rebase to the trunk which replace target_phys_addr_t with hwaddr everywhere. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH v2 0/7] TCG global variables clean-up
On Thu, Oct 25, 2012 at 07:06:37AM +0400, Evgeny Voevodin wrote: Any other comments on the patches? I didn't get the consensus. Do we need a pointer to tcg context? As I said before, I didn't notice any slow-down with it. On 10/23/2012 10:21 AM, Evgeny Voevodin wrote: This set of patches moves global variables to tcg_ctx: gen_opc_ptr gen_opparam_ptr gen_opc_buf gen_opparam_buf Build tested for all targets. Execution tested on ARM. I didn't notice any slow-down of kernel boot after this set was applied. Would you like to try to run some benchmark after the kernel booting? Like Yeongkyoon Lee done with his qemu_ld/qemu_st work [1], EEMBC, nbench , or even SPEC. ;) Regards, chenwj [1] http://lists.gnu.org/archive/html/qemu-devel/2012-10/msg03630.html -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [RESEND PATCH v6 2/3] tcg: Add extended GETPC mechanism for MMU helpers with ldst optimization
Hi Yeongkyoon, +#if defined(CONFIG_QEMU_LDST_OPTIMIZATION) defined(CONFIG_SOFTMMU) +/* check whether the give addr is in TCG generated code buffer or not */ should be given. Cheers, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [RESEND PATCH v6 2/3] tcg: Add extended GETPC mechanism for MMU helpers with ldst optimization
On Wed, Oct 24, 2012 at 12:11:23PM +0900, Yeongkyoon Lee wrote: On 2012년 10월 24일 00:25, 陳韋任 (Wei-Ren Chen) wrote: Hi Yeongkyoon, +#if defined(CONFIG_QEMU_LDST_OPTIMIZATION) defined(CONFIG_SOFTMMU) +/* check whether the give addr is in TCG generated code buffer or not */ should be given. Cheers, chenwj Thanks a lot, Wei-Ren. Probably I should send the next version of the patch. Or someone who commits this patchset for you can fix typo so that you don't have to resend it. ;) Cheers, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] Any alternative to kqemu ?
Is there an alternative to it ? No. That is tough ... ! So my hardware is officially obsolete. I had to get away with those other emulators provided by commercial companies. VMWare said my hardware does not support virtualization (much like qemu), but VirtualBox worked surprisingly well and uses the CPU natively (no emulation, faster than my qemu without kvm). IIRC, VirtualBox take approach similar to kqemu does, i.e., translate privilege instructions only and run non-privilege instructions on host cpu directly. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] MIPS DSP for Qemu
Since the topic has come up, what is the process for vetting a maintainer? Well, I can tell you the process I went through in becoming a co-maintainer for the ARM target (about a year or so ago now). Basically I started out by doing a bunch of work that seemed to need doing and that nobody else was doing at the time: * submitting patches to fix various bugs * reviewing patches other people sent to the list * generally taking part in discussions on list and irc * collecting up patches and making sure they didn't get forgotten * progressing to putting together a tree and starting to send pull-request emails and about the last thing was getting the MAINTAINERS file changed to add my name. If there was a formal vetting process I didn't notice it :-) This could be put on wiki page so that people who want to be a maintainer know what they should do. :) Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] MIPS DSP for Qemu
I would like to still submit our patches . Please advise. Out port is complete and already tested to a level which would be difficult for someone else to do that does not have access to our AVP test suite. What about Jia's patch? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
[Qemu-devel] Any other cross ISA and system mode binary translator like QEMU?
Hi all, Most binary translators I am aware of are user mode, i.e., they are only used to run guest application not OS. The system mode binary translators which do cross ISA translation I know so far are Transmeta CMS, IBM DAISY and QEMU. Any others out there? Thanks. Regards, chenwj [1] -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] Dynamic Binary Instrumentation
On Fri, Sep 21, 2012 at 03:39:32PM +0200, Lluís Vilanova wrote: Sorry, it's up again. The server is low on RAM and Linux' OOM killer kicks in sometimes. Thanks. I am playing around your qemu-dbi, and has error below. $ make LINK i386-softmmu/qemu-system-i386 translate.o: In function `trace_tcg_instr__before': /tmp/chenwj/qemu-dbi/trace/tcg-instr-internal.h:134: undefined reference to `trace_tcg_vbbl_before' Seems some files or functions are missing? Also, do you consider move your repo to github or other more reliable server? Regards, chenwj P.S. Attach is a minor patch which fix a typo (I guess). -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj diff --git a/docs/instrumentation.txt b/docs/instrumentation.txt index 58ce4cb..c2e79b0 100644 --- a/docs/instrumentation.txt +++ b/docs/instrumentation.txt @@ -39,7 +39,7 @@ property, if any) in the events listed in the trace-events file. In order to avoid modifying the QEMU sources, you can simply create a new trace-events file with your modifications: -cp /path/to/qemu-source/ /tmp/trace-events +cp /path/to/qemu-source/trace-events /tmp/trace-events sed -i -e s/qemu_vmalloc(/instrument qemu_vmalloc(/g /tmp/trace-events sed -i -e s/disable tcg vbbl_before(/instrument tcg vbbl(/g /tmp/trace-events sed -i -e s/disable tcg vinstr_before_before(/instrument tcg vinstr_before(/g /tmp/trace-events
Re: [Qemu-devel] Dynamic Binary Instrumentation
Hi Liuis, On Tue, Sep 04, 2012 at 10:08:09PM +0200, Lluís Vilanova wrote: Hi there, Given that right now I don't have enough time to write the paper that should accompany this work, I've decided to open it up so that whoever is interested can have access to it. You can get some instructions here: https://projects.gso.ac.upc.edu/projects/qemu-dbi/wiki The website is down. :/ Would you like to take a look on that? Thanks. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] Any plan to support armv8 emulation
Hi, On Thu, Sep 20, 2012 at 11:42:18AM +0800, Michael.Kang wrote: Is there any developers who have plan to support armv8 emulation? Or have some initial roadmap for support of armv8? I know there is already armv8 patch merged into linux kernel. Never hear of such plan so far. Would you interest in contributing this part? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] Does TCG IR use static single assignment (SSA) form?
Excuse me for asking, does TCG-IR use static single assignment (SSA) form? I just wanna know how to translate a register-based bytecode to TCG-IR. Sounds like you need to take a look at target-xxx/translate.c ? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] TCG questions
I have created a set of instrument API on QEMU. one can write client programs that compile into shared library. the shared library is then loaded into qemu and extract statistics out of QEMU. Instrument API? Same as what Liuis did? Regards, chenwj [1] http://lists.gnu.org/archive/html/qemu-devel/2012-09/msg00379.html -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] Virtual Machine Extension Instructions In QEMU
On Wed, Sep 05, 2012 at 10:00:01AM -0700, Xin Tong wrote: I would like to know how well is the Intel VMX and AMD SVM supported in QEMU ? IIRC, AMD SVM has been supported in QEMU (but not complete). You can check target-i386/translate.c, and this is mentioned in changelog [1]. Alex, can you confirm this? I am not sure how complete AMD SVM support in QEMU. :) Regards, chenwj [1] http://wiki.qemu.org/ChangeLog/old -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] QEMU emulation per CPU
On Fri, Aug 31, 2012 at 01:50:05AM +0700, Mulyadi Santosa wrote: On Thu, Aug 30, 2012 at 7:27 PM, Naresh Bhat nareshgb...@gmail.com wrote: Hi Santosa, Can you please forward a link of that discussion thread ?? try: http://lists.nongnu.org/archive/html/qemu-devel/2012-08/msg05037.html I also think multithread support in qemu user mode is buggy, not only the issue mentioned on above thread. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
[Qemu-devel] [ANN] Hellogcc 2012 Workshop, Beijing, Nov. 10th
Hellogcc 2012 Workshop, Beijing, Nov. 10th HelloGcc 2012 Workshop calls for topic speakers. HelloGcc Working Group was set up in 2007 by Chinese free software fans and developers in Beijing. With the goal of constructing a free, open, sharing technical community, we not only discuss and learn about GNU toolchains (such as GCC, GDB, Binutils etc), QEMU and LLVM ... etc, provide helps on related study and work, but also make our contributions to free software community. Every year, we hold a technical workshop in order to improve communication among open source developers and fans. The activity will be held on Nov. 10th this year. We're calling for topic speakers now. As soon as you prefer to give a technical report, welcome to contact us. Topics includes, but not limited to, * Introduction on your original work, or the work of others. * Researching work or engineering work. * Code explanation and program demonstration. We need to get the speaker's slides ahead of time and post it on the Internet, with author's approval. It's better if you intend to provide the text of articles, of course. The whole activity is free. We hope to get some sponsorship to be used as the reward of speakers and the support of the community development. Please send mail to following address below if you have any questions on this workshop: hellogcc.workgr...@gmail.com Note: Topics in HelloGCC 2011 Workshop * Introduction to GCC Backend * GNU Tools for ARM Embedded Processors * Displaced stepping and its implementation for Thumb-2. * Performance of binary translation between TCG and LLVM. * The new era of GCC: Plugin Topics in HelloGcc 2010 Workshop * Memory management mechanism and optimization * Discussion on debugger's breakpoint mechanism * Bintuils porting to embedded CPU * Implementation and discussion on visualization of GCC * How To Port GNU ToolChain * Demo of Linux Kernel GDB tracepoint module Topics in HelloGcc 2009 Workshop. * Analyze and improve the program's data locality with GCC * GCC Internals and Porting * gdbproxy: An open source GDB stub for Blackfin * GDB reverse debug and process record and replay target You can find us on * blog: http://www.hellogcc.org * mail list: http://www.freelists.org/archive/hellogcc * irc: #hellogcc on freenode -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] qemu log function to print out the registers of the guest
My final goal is to obtain the memory access trace for a particular process in the guest, so your patch really helps, except for too many kernel _mmu events. How do you know guest is running which process, and log it's memory access trace? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] How to add new architecture?
On Fri, Aug 24, 2012 at 05:46:43PM -0700, Michael Eager wrote: Is there a description of how to add a new processor architecture to QEMU? I looked at the Wiki and at the QEMU-Buch, but there doesn't seem to be anything on topic. Looking for target-xxx/ if you want to add a new guest, tcg/xxx/ if you want to add a new host. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] Get host virtual address corresponding to guest physical address?
On Sat, Aug 25, 2012 at 11:56:13AM +0100, Peter Maydell wrote:
On 24 August 2012 04:14, 陳韋任 (Wei-Ren Chen) che...@iis.sinica.edu.tw wrote:
I would like to know if there is a function in QEMU which converts
a guest physical address into corresponding host virtual address.
So the question is, what do you want to do with the host virtual
address when you've got it? cpu_physical_memory_map() is really intended
(as Blue says) for the case where you have a bit of host code that wants
to write a chunk of data and doesn't want to do a sequence of
cpu_physical_memory_read()/_write() calls. Instead you _map() the memory,
write to it and then _unmap() it.
We want to let host MMU hardware to do what softmmu does. As a prototype
(x86 guest on x86_64 host), we want to do the following:
1. Get guest page table entries (GVA - GPA).
2. Get corresponding HVA.
3. Then we use /dev/mem (with host cr3) to find out HPA.
4. We insert GVA - HPA mapping into host page table through /dev/mem,
we already move QEMU above 4G to make way for the guest.
So we don't write data into the host virtual addr.
Note that not all guest physical addresses have a meaningful host
virtual address -- in particular memory mapped devices won't.
I guess in our case, we don't touch MMIO?
1. I am running x86 guest on a x86_64 host and using the cod below
to get the host virtual address, I am not sure what value of len
should be.
The length should be the length of the area of memory you want to
either read or write from.
Actually I want to know where guest page are mapped to host virtual
address. The GPA we get from step 1 points to guest page table, and
we want to know its corresponding HVA.
static inline void *gpa2hva(target_phys_addr_t addr)
{
target_phys_addr_t len = 4;
return cpu_physical_memory_map(addr, len, 0);
}
If you try this on a memory mapped device address then the first
time round it will give you back the address of a bounce buffer,
ie a bit of temporary RAM you can read/write and which unmap will
then actually feed to the device's read/write functions. Since you
never call unmap, this means that anybody else who tries to use
cpu_physical_memory_map() on a device from now on will get back
NULL (meaning resource exhaustion, because the bouncebuffer is in
use).
You mean if I call cpu_physical_memory_map with a guest MMIO (physcial)
address, the first time it'll return the address of a buffer that I can write
data into. The second time it'll return NULL since I don't call
cpu_physical_memory_umap to flush the buffer. Do I understand you correctly?
Hmm, I think we don't not have such issue in our use case... What do you
think?
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] How to add new architecture?
I want to add a new guest architecture.
Is there any description of what the configuration options mean?
You mean the options list in `../${QEMU_SRC}/configure --help`?
Not sure why you need to care about that.
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] How to add new architecture?
On Sat, Aug 25, 2012 at 08:33:41AM -0700, Michael Eager wrote: On 08/25/2012 05:57 AM, 陳韋任 (Wei-Ren Chen) wrote: On Fri, Aug 24, 2012 at 05:46:43PM -0700, Michael Eager wrote: Is there a description of how to add a new processor architecture to QEMU? I looked at the Wiki and at the QEMU-Buch, but there doesn't seem to be anything on topic. Looking for target-xxx/ if you want to add a new guest, tcg/xxx/ if you want to add a new host. I want to add a new guest architecture. I suggest you take a look on openrisc patchset [1], it's a relative new added guest support. Regards, chenwj [1] https://lists.gnu.org/archive/html/qemu-devel/2012-07/msg02567.html -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] How to add new architecture?
On Sat, Aug 25, 2012 at 08:50:29AM -0700, Michael Eager wrote:
On 08/25/2012 08:38 AM, 陳韋任 (Wei-Ren Chen) wrote:
I want to add a new guest architecture.
Is there any description of what the configuration options mean?
You mean the options list in `../${QEMU_SRC}/configure --help`?
Not sure why you need to care about that.
In $QEMU_SRC/configure, architectures have these configuration options
(and several more):
target_nptl=yes
target_phys_bits=32
target_libs_softmmu=$fdt_libs
In the target-*/cpu.h, there are defines like:
#define TARGET_LONG_BITS 32
#define TARGET_HAS_ICE 1
#define TARGET_PAGE_BITS 12
#define TARGET_PAGE_BITS 10
#define TARGET_PHYS_ADDR_SPACE_BITS 40
#define TARGET_VIRT_ADDR_SPACE_BITS 32
There are also required specification like CPUState or CPUArchState.
Is there any description of these configuration options?
Well, you need to read the source code. :) Basically, TARGET_XXX
describes guest characteristics. QEMU now is refactoring its code base,
for example, perfer to use CPUArchState rather than CPUState. OpenRISC
port is a good example/template you can use.
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] passing translated address out in QEMU
not too sure how much impact inlined lookup has on the performance. since i disabled it, next step i would just get rid of that piece of generated assembly, as it is no good for icache ( generated for every memory operation). You can run a benchmark inside your guest. I guess if you run a long-running benchmark, you can see performance degradation. If software tlb hit, you can get the value of guest memory in the code cache with a few host instructions. Disabling software tlb lookup, every guest memory access will call a helper function which takes a lot of time. What you mean by get rid of that piece of generated assembly? every inlined TLB lookup has ~10 instructions . I still don't think remove inline tlb lookup will improve anything. True, the inline tlb lookup will take some space on icache, but I believe it's not a big deal since you're on a x86 host. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] What's the proper type of guest pde address, target_ulong or target_phys_addr_t?
In principle, yes, but you need to check the code carefully to make sure your type change doesn't change any of the results. (Or if it does, you then need to confirm against the specs that this was a bug that is being fixed, not a new one being introduced). The thing you have to remember is that for the 32 bit x86 cores guest physical addresses are only 32 bits but target_phys_addr_t is still a 64 bit type. Yes, I saw in configure x86 and x86_64 both have target_phys_bits set to 64. --- case $target_arch2 in i386) target_phys_bits=64 ;; if test $target_softmmu = yes ; then echo TARGET_PHYS_ADDR_BITS=$target_phys_bits $config_target_mak --- So that in targphys.h, it typedef target_phys_addr_t to uint_64, #elif TARGET_PHYS_ADDR_BITS == 64 typedef uint64_t target_phys_addr_t; It may be we're deliberately (mis)using target_ulong to get the right behaviour on both 32 and 64 bit cores. Need to be further investigated. :) Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] What's the proper type of guest pde address, target_ulong or target_phys_addr_t?
In principle, yes, but you need to check the code carefully to make
sure your type change doesn't change any of the results. (Or if it
does, you then need to confirm against the specs that this was a bug
that is being fixed, not a new one being introduced). The thing you have
to remember is that for the 32 bit x86 cores guest physical addresses
are only 32 bits but target_phys_addr_t is still a 64 bit type.
It may be we're deliberately (mis)using target_ulong to get the
right behaviour on both 32 and 64 bit cores.
Just want to make a note here. According to Intel Software Developer's Manual
Volume 3A, 4.4.2 Linear-Address Translation with PAE Paging [1],
A PDE is selected using the physical address defined as follows:
- Bits 51:12 are from PDPTEi.
- Bits 11:3 are bits 29:21 of the linear address.
- Bits 2:0 are 0.
IIUC, pde_addr/pte_addr are 52-bit wide, but cpu_get_phys_page_debug
declares pde_addr/pte_addr as target_ulong, which is uint32_t for x86
guest. That might be a problem.
target_phys_addr_t cpu_get_phys_page_debug(CPUX86State *env, target_ulong addr)
{
target_ulong pde_addr, pte_addr;
... snip ...
}
Regards,
chenwj
[1]
http://download.intel.com/products/processor/manual/253668.pdf
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] passing translated address out in QEMU
On Wed, Aug 22, 2012 at 09:38:17PM -0700, Xin Tong wrote:
On Wed, Aug 22, 2012 at 8:14 PM, 陳韋任 (Wei-Ren Chen)
che...@iis.sinica.edu.tw wrote:
In tcg_gen_qemu_ld8s(tmp, addr, index); a TCGv addr is passed to the
INDEX_op_qemu_ld8s as param and the loaded value is passed back in
tmp. i want to get the translated value as well. how can i do that ?
IIUC, qemu_ld takes addr as guest virtual address, then loads the
value in that address into tmp. So, what translated value you mean
here? The guest physical address, host virtual address, or the value
of the guest virtual address?
either the guest physical or the host virtual is fine with me. but
better to be guest physical. i think guest physical can be obtained by
subtracting host virtual with a fixed offset for ram. but the thing i
do not know how to do is how to pass the guest physical back, can i
store the guest physical in the TCGv from the guest virtual.
qemu_ld will go through software tlb first, you will get host virtual
address there. It will go ld{b,w,l,q}_mmu if software tlb miss, call
tlb_fill - cpu_x86_handle_mmu_fault, you can get guest physical address
there (target_phys_addr_t paddr). If you want to get guest physical
address for each guest memory access, I guess you need to disable
software tlb lookup, you can refer to Max's patch [1]. Or as you said,
maybe you can get guest physical addr from host virtual addr. You can
refer to cpu_physical_memory_map (exec.c) which map guest physical addr
to host virtual addr, then see how you can do the reverse.
HTH,
chenwj
[1] http://lists.gnu.org/archive/html/qemu-devel/2012-08/msg03226.html
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] passing translated address out in QEMU
subtracting host virtual with a fixed offset for ram. but the thing i do not know how to do is how to pass the guest physical back, can i store the guest physical in the TCGv from the guest virtual. Maybe you can store it on a host unused register, perhaps xmm0? ;) Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] passing translated address out in QEMU
even that. is it possible to pass host virtual out. the fast path add the addend to get host virtual ? so it must be in a register, most likely eax in i386. what do you think would be the best way to get that out ? Take a look on comment on tcg_out_tlb_load (tcg/i386/tcg-target.c). First argument register is loaded with the low part of the address. In the TLB hit case, it has been adjusted as indicated by the TLB and so is a host address. In the TLB miss case, it continues to hold a guest address. So I guess you can take tcg_target_call_iarg_regs[0] as host virtual address if software tlb hit. /* TLB Hit. */ tcg_out_qemu_ld_direct(s, data_reg, data_reg2, tcg_target_call_iarg_regs[0], 0, opc); As for how do you get host virtual address out, I think you can write a helper function logging those host virtual address into a file or something else, then insert a helper function call at the point of TLB hit. HTH, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
[Qemu-devel] Get host virtual address corresponding to guest physical address?
Hi all,
I would like to know if there is a function in QEMU which converts
a guest physical address into corresponding host virtual address. I
guess cpu_physical_memory_map (exec.c) can do the job, but I have a
few questions.
1. I am running x86 guest on a x86_64 host and using the cod below
to get the host virtual address, I am not sure what value of len
should be.
static inline void *gpa2hva(target_phys_addr_t addr)
{
target_phys_addr_t len = 4;
return cpu_physical_memory_map(addr, len, 0);
}
2. There is a function cpu_physical_memory_unmap, the comment
of it says,
Unmaps a memory region previously mapped by cpu_physical_memory_map().
That makes me not sure if I use cpu_physical_memory_map correctly,
does it do what I want to do?
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
[Qemu-devel] What's the proper type of guest pde address, target_ulong or target_phys_addr_t?
Hi all,
When I read cpu_get_phys_page_debug (target-i386/helper.c), I found
the type of pde_addr and pte_addr might be not correct. See below,
---
target_phys_addr_t cpu_get_phys_page_debug(CPUX86State *env, target_ulong addr)
{
target_ulong pde_addr, pte_addr;
...
pde_addr = ((pdpe ~0xfff ~(PG_NX_MASK | PG_HI_USER_MASK)) +
(((addr 21) 0x1ff) 3)) env-a20_mask;
pde = ldq_phys(pde_addr);
...
}
---
HACKING says target_ulong is for guest virtual address and target_phys_addr_t
is for guest physical address. IIUC, pde_addr and pte_addr should be the
guest physical address for guest page table and guest page respectively,
right? If no one object, I'll send a patch which replaces target_ulong
with target_phys_addr_t.
Thanks.
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] passing translated address out in QEMU
That might be difficult. what i did was that i disabled inlined
translated and push the virt/phys address into 2 new fields in the cpu
structure in the call out lookup. because in the callout lookup we
have a handle to the cpu env.
What you mean by disabled inlined translated? You mean apply Max's
patch so that all guest memory access go through the slow path without
looking software tlb? Since you said you're running arm on x86 host,
I guess what you did might be,
int cpu_arm_handle_mmu_fault (CPUARMState *env, target_ulong address,
int access_type, int mmu_idx)
{
...
ret = get_phys_addr(env, address, access_type, is_user, phys_addr, prot,
page_size);
// store phys_addr into env-cpu_last_paddr
...
}
not too sure how much impact inlined lookup has on the performance.
since i disabled it, next step i would just get rid of that piece of
generated assembly, as it is no good for icache ( generated for every
memory operation).
You can run a benchmark inside your guest. I guess if you run a
long-running benchmark, you can see performance degradation. If software
tlb hit, you can get the value of guest memory in the code cache
with a few host instructions. Disabling software tlb lookup, every guest
memory access will call a helper function which takes a lot of time.
What you mean by get rid of that piece of generated assembly?
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] Dump guest page table inside QEMU makes system hang
The system will hang while booting. However, if I comment
cpu_physical_memory_read in function dump_guest_pgtable, there
is no problem. What I am missing here? Thanks.
cpu_physical_memory_read() can cause faults or other side effects like
MMIO. Using cpu_get_phys_page_debug() may help.
Maybe you just need to avoid accessing unsuitable physical addresses?
Or maybe 'if (env-cr[0] CR0_PG_MASK)' is not strong enough, may
(CR0_PG_MASK | CR0_PE_MASK) be better?
At what stage does it hang? What CR3 value changes are observed before
the hang?
It's quite embarrassing. The code I posted before is buggy, and it dumps all
1024 * 1024 page table entries. It takes a lot of time, so that I think the
system hangs. Attach is the code snipt what I am using, which works fine now.
Another question is, I would like to know the hva corresponding to gpa (i.e.,
the guest page pointed by guest pte). Do you happen to know there is such
gpa2hva function in QEMU?
Thanks.
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
// we only consider x86 w/o pae
static void dump_guest_pgtable(CPUX86State *env)
{
int i, j;
target_ulong pde_addr, pte_addr;
target_ulong phyaddr, phyaddr2;
uint32_t pde, pte;
pde_addr = (env-cr[3] ~0xfff) env-a20_mask;
// first level page directory, iterate pde
for (i = 0; i NUM_ENTRY; ++i)
{
phyaddr = (pde_addr + i * 4) env-a20_mask;
pde = ldl_phys(phyaddr);
pd[i] = pde;
if (!(pde PG_PRESENT_MASK))
continue;
pte_addr = (pde ~0xfff) env-a20_mask;
// second level page table, iterate pte
for (j = 0; j NUM_ENTRY; ++j)
{
phyaddr2 = (pte_addr + j * 4) env-a20_mask;
pte = ldl_phys(phyaddr2);
if (!(pte PG_PRESENT_MASK))
pt[i][j] = 0;
pt[i][j] = pte;
}
}
}
Re: [Qemu-devel] passing translated address out in QEMU
In tcg_gen_qemu_ld8s(tmp, addr, index); a TCGv addr is passed to the INDEX_op_qemu_ld8s as param and the loaded value is passed back in tmp. i want to get the translated value as well. how can i do that ? IIUC, qemu_ld takes addr as guest virtual address, then loads the value in that address into tmp. So, what translated value you mean here? The guest physical address, host virtual address, or the value of the guest virtual address? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] Dump guest page table inside QEMU makes system hang
It's quite embarrassing. The code I posted before is buggy, and it dumps all 1024 * 1024 page table entries. It takes a lot of time, so that I think the system hangs. Attach is the code snipt what I am using, which works fine now. Another question is, I would like to know the hva corresponding to gpa (i.e., the guest page pointed by guest pte). Do you happen to know there is such gpa2hva function in QEMU? I think I found one, cpu_physical_memory_map (exec.c). Below is how I convert gpa to hva by using cpu_physical_memory_map. target_ulong pde_addr = (env-cr[3] + 32 * 4) env-a20_mask; target_phys_addr_t len = 4; void *ptr = cpu_physical_memory_map(pde_addr, len, 0); The only thing I am not sure about is what value of len I should use. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
[Qemu-devel] Dump guest page table inside QEMU makes system hang
Hi all,
I want to dump guest page table when guest writes to cr3,
the code snipt below,
---
uint32_t pgd[1024][1024]; // guest page table
static void dump_guest_pgtable(target_ulong cr3)
{
int i, j;
uint32_t phyaddr = cr3;
uint32_t val;
for (i = 0; i NUM_ENTRY; ++i)
{
phyaddr += i * 4;
for (j = 0; j NUM_ENTRY; ++j)
{
cpu_physical_memory_read(phyaddr, val, 4);
pgd[i][j] = val;
}
}
}
void cpu_x86_update_cr3(CPUX86State *env, target_ulong new_cr3)
{
env-cr[3] = new_cr3; // guest cr3
if (env-cr[0] CR0_PG_MASK) {
tlb_flush(env, 0);
// dump guest page table by using guest cr3
dump_guest_pgtable(new_cr3);
}
}
---
The system will hang while booting. However, if I comment
cpu_physical_memory_read in function dump_guest_pgtable, there
is no problem. What I am missing here? Thanks.
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
