Re: [Qemu-devel] icount and tb chaining
On Wed, Jan 18, 2012 at 07:50:19PM +, Peter Maydell wrote: On 18 January 2012 19:43, James Greensky gsk...@gmail.com wrote: On Tue, Jan 17, 2012 at 7:03 PM, 陳韋任 che...@iis.sinica.edu.tw wrote: I think those numbers (0, 1, and 2) means tb_add_jump 2nd parameter here, so it's intentionally to check jmp_first when n is 2. Since tb-jmp_first is never to be zero, then condition is always false (do nothing) when n is 2. Chenwj, you are correct, the check bypasses the whole function, I was not paying enough attention to that check, it should never be null, in which case the code doesn't get executed and the chaining remains unchanged. The question that occurs to me is, is this working like this by design, or is it a bug that just happens to have no ill effects? The fact that the condition in tb_add_jump() is commented as only needed for thread safety suggests the latter to me... `git blame` shows Fabrice wrote that comment, so maybe only he knows the real reason. Is the thread in the comment the same as in multi-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] The comment of cpu-exec.c might be wrong?
Hi all, The comment of cpu-exec.c says it's i386 emulator main execution loop. IIUC, each target use #define marco to rename cpu_exec to cpu_xxx_exec in target-xxx/cpu.h, then defines its own cpu_loop which calls cpu_xxx_exec (which basically is cpu_exec in cpu-exec.c). If it's O.K., I'll send a patch to correct this comment. Any comment? 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] Fwd: envlist_setenv...
On Tue, Jan 17, 2012 at 09:54:36PM +0100, Davide wrote:
What does this loop in main?
for (wrk = environ; *wrk != NULL; wrk++) {
(void) envlist_setenv(envlist, *wrk);
}
Seems the return value (error code) of envlist_setenv is ignored here...
--
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] Fwd: envlist_setenv...
Hi,
What does this loop in main?
for (wrk = environ; *wrk != NULL; wrk++) {
(void) envlist_setenv(envlist, *wrk);
}
You can check envlist.[ch] first. I think what the loop does is copying host
environ (user environment. HOME, SHELL, PATH...etc) to struct envlist
(envlist.c).
Latter on, QEMU calls function envlist_to_environ to transform envlist to target
environ which is used by the guest application.
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] Get only TCG code without execution
What is the way out of this? The reason I need TCG code is because my project work is to write a semantics for TCG micro-operations and then compare my semantics with a semantics for ARM instructions being written by someone else. To test my semantics, I need the corresponding TCG code for several different multi-threaded ARM binaries. Why does this have to be a multi-threaded binary? In the multithreaded case, the instructions executed by QEMU won't be deterministic (it will depend on how the host OS schedules the multiple threads) so it's going to be hard to compare a long trace output to something else. I guess Rajat's goal is to compare the semantics of TCG ops and ARM binary, therefore the non-deterministic might not be the issue. Or he want to use semantics to solve the non-deterministic problem. 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] icount and tb chaining
a jump with the least significant bits = 2. This falls through to tb
add jump, which then updates the jmp_first field of the current tb.
I don't know if tb_add_jump's second parameter will be two or not, but
look at TranslationBlock (exec-all.h),
struct TranslationBlock {
struct TranslationBlock *jmp_next[2];
}
and tb_add_jump (exec-all.h).
static inline void tb_add_jump(TranslationBlock *tb, int n,
TranslationBlock *tb_next)
{
/* NOTE: this test is only needed for thread safety */
if (!tb-jmp_next[n]) { --- what if n is 2?
}
}
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] Question about tlb_flush
On Fri, Jan 13, 2012 at 11:57:36AM +0800, 陳韋任 wrote: Hi all, When I looked at function tlb_flush (exec.c), I found its second parameter flush_global is never used. In tlb_flush comment, it says if flush_global is true, also flush global entries (not implemented yet) Does anyone know what the global entries are? Thanks. Peter has sent a patch to clarify it. :) http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg02156.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] icount and tb chaining
if (!tb-jmp_next[n]) { --- what if n is 2?
This is my question, if n is two, it would actually be checking the
jmp_first field immediatedly following the jmp_next array in the tb
structure. This function only updates the jmp_first field and doesn't
touch jmp_next when n is 2. Does anybody know why this is? It seems
like you would like to leave the tb chaining as it was, because you
are going to execute the same translation block again, it just jumped
out to replenish the icount_decr counter. -Jim
I set a conditional breakpoint at tb_add_jump to watch what happened when
n is 2. Look at tb_link_page (exec.c) first, which initializes some fields of
a TranslatioBlock.
void tb_link_page(TranslationBlock *tb, ...)
{
tb-jmp_first = (TranslationBlock *)((long)tb | 2);
tb-jmp_next[0] = NULL;
tb-jmp_next[1] = NULL;
}
And look at struct TranslationBlock (exec-all.h),
struct TranslationBlock {
/* list of TBs jumping to this one. This is a circular list using
the two least significant bits of the pointers to tell what is
the next pointer: 0 = jmp_next[0], 1 = jmp_next[1], 2 =
jmp_first */
struct TranslationBlock *jmp_next[2];
struct TranslationBlock *jmp_first;
}
I think those numbers (0, 1, and 2) means tb_add_jump 2nd parameter here, so
it's intentionally to check jmp_first when n is 2. Since tb-jmp_first is never
to be zero, then condition is always false (do nothing) when n is 2. You said
This function only updates the jmp_first field and doesn't touch jmp_next
when n is 2
Do you mean in some case (tb-jmp_first == 0) it might execute the following
code when n is 2? Because I don't see tb_add_jump updates jmp_first and leave
jmp_next alone when n is 2, it just do nothing.
tb_set_jmp_target(tb, n, (unsigned long)tb_next-tc_ptr);
tb-jmp_next[n] = tb_next-jmp_first;
tb_next-jmp_first = (TranslationBlock *)((long)(tb) | (n));
Your guess makes sense to me,
It seems like you would like to leave the tb chaining as it was, because you
are going to execute the same translation block again, it just jumped out to
replenish the icount_decr counter
And talk about the meaning of last significant bits of TranslationBlock*. AFAIK,
if last significant bits of TranslationBlock* are set to 2, then it means the
circular list of block chaining is stopped at this TranslationBlock. For
example, if tb1 links to tb2 (tb1 - tb2), then
tb1-jmp_next = tb2 | 2
tb2-jmp_first = tb1 | 1
You can check the slide below if you want. It illustates how those fields
(jmp_first and jmp_next) are used in block chaining.
http://www.hellogcc.org/wp-content/uploads/2011/10/QEMU-block-chaining.ppt
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] icount and tb chaining
previously returned tb. This is usually 0/1. When running icount, you can also get a 2 value in these least significant digits, indicating that the translation block was restarted due to the icount_decr.u16.low field being exhausted but having instructions left to execute in icount_extra. This 2 value falls through to tb_add_jump, which then updates the tb's jmp_first field, as both tb and next_tb refer to the same translation block. My question is why is this necessary, why not do nothing, and leave the previous chaining intact? I hope this is clearer and thanks for the response. -Jim I have a question here. Look at gen_icount_start and gen_icount_end in gen-icount.h, I think the least significant bits are set to 2 by following code. tcg_gen_exit_tb((tcg_target_long)tb + 2); And you said, indicating that the translation block was restarted due to the icount_decr.u16.low field being exhausted but having instructions left to execute in icount_extra. From the code snipt of gen_icount_start below, I can only figure out something (icount_decr.u32?) is exhausted so it will jump to label set by gen_icount_end and execute tcg_gen_exit_tb((tcg_target_long)tb + 2). I only see icount_extra and icount_decr.u16.low are dealt in cpu_exec (cpu-exec.c). Do I miss something or misunderstand what you said? Thanks. --- icount_label = gen_new_label(); count = tcg_temp_local_new_i32(); tcg_gen_ld_i32(count, cpu_env, offsetof(CPUState, icount_decr.u32)); /* This is a horrid hack to allow fixing up the value later. */ icount_arg = gen_opparam_ptr + 1; tcg_gen_subi_i32(count, count, 0xdeadbeef); tcg_gen_brcondi_i32(TCG_COND_LT, count, 0, icount_label); --- 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] throwing away translated code on CPU reset
On Thu, Jan 12, 2012 at 02:00:38PM +, Peter Maydell wrote:
When doing TCG code translation, the target-foo translate.c
code is allowed to bake assumptions into the generated code from
the current values of various fields in the CPUState. This then
imposes the requirement that if the field is changed then tb_flush
must be called to throw away the now-incorrect generated code.
However, cpu_reset() changes (unsurprisingly) lots of fields in
the CPUState, but it doesn't call tb_flush()...
I dig what tlb_flush does further and think maybe we don't need to call
tb_flush
when tlb_flush is called.
First, look at tlb_flush (exec.c). It clears env's tb_jmp_cache which use GHA
as an index to search if there is a translated code. Since tb_jmp_cache is reset
now, QEMU is forced to call tb_find_slow which uses GPA as the index.
In tb_find_slow's for loop, it compares hit TranslationBlock's various fields
with current values. To be more specific,
static TranslationBlock *tb_find_slow(...) {
for(;;) {
tb = *ptb1;
if (!tb)
goto not_found;
if (tb-pc == pc --- Here
tb-page_addr[0] == phys_page1
tb-cs_base == cs_base
tb-flags == flags) {
}
}
}
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] icount and tb chaining
On Thu, Jan 12, 2012 at 11:00:43AM -0800, James Greensky wrote: Hello all, I have a question about icount and tb chaining that I hope somebody can clear up. In cpu-exec.c, when the icount_decr.u16.low counter expires, it passes back the current tb as the next_tb and add a jump with the least significant bits = 2. This falls through to tb add jump, which then updates the jmp_first field of the current tb. why is this done? Thanks -Jim Could you elaborate on the whole sequence? I am not sure where should I look into to answer your question. 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
[Qemu-devel] Question about tlb_flush
Hi all, When I looked at function tlb_flush (exec.c), I found its second parameter flush_global is never used. In tlb_flush comment, it says if flush_global is true, also flush global entries (not implemented yet) Does anyone know what the global entries are? 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
[Qemu-devel] Does iotlb have anything to do with IOMMU?
Hi all, I am wondering if iotlb (cpu-defs.h) has anything to do with IOMMU [1]. I think iotlb is used in MMIO (memory mapped IO), right? Thanks for clarification. [1] http://en.wikipedia.org/wiki/IOMMU 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] add debugger command
Hi Cheung, On Wed, Dec 28, 2011 at 05:40:20AM +, Peter Cheung wrote: Dear QEMU team I want to add some debug command for qemu so my peter-bochs (http://peter-bochs.googlecode.com) debugger can support qemu. So I have these questions:1) QEMU use SVN?2) How to apply a role to submit code to their svn? A1. It use git. See http://wiki.qemu.org/Download . A2. 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] MIIPS64el compiler
any one of you know about MIPS64el cross compiler? I would appreciate your response.. Not sure if http://developer.mips.com/clang-llvm/ support MIPS64el, but you can give it a try. ;) 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] Use Clang to compile Qemu?
Hi all, I am trying to build QEMU by using clang, but get error message below. --- In file included from /z/tmp/chenwj/qemu-1.0/user-exec.c:21: /z/tmp/chenwj/qemu-1.0/dyngen-exec.h:64:20: error: global register variables are not supported register CPUState *env asm(AREG0); ^ 1 warning and 1 error generated. --- Any idea on how to work around this? 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] Use Clang to compile Qemu?
On Fri, Dec 23, 2011 at 02:07:53PM +0100, David Turner wrote: Some parts of QEMU (the JIT) require the use of a global register variable to point to the env CPU state variable. This feature is not supported by Clang (which is not very surprising given that it uses LLVM as its backend, and LLVM explicitely doesn't support this) Until the JIT is modified to not require this anymore, it is very unlikely that Clang will be able to build QEMU. There were previous discussions about such a change on this mailing list, but I believe nobody started working on that change because many feared it was a lot of work that would have a negative impact on performance (though I think it was all conjecture, i.e. no one really tried it and got any real data). You're right. Here is the discussion, http://lists.gnu.org/archive/html/qemu-devel/2011-05/msg01116.html Since TCI (Tiny Code Interpreter) doesn't need AREG0, I configure QEMU to use TCI and try it out. Here's my flow. --- # apply patches under /usr/ports/emulators/qemu-devel/files/ first $ ../configure --prefix=$INSTALL --target-list=i386-bsd-user \ --enable-tcg-interpreter \ --cc=clang $ gmake install --- So far so good (perhaps freebsd guys should upstream those patches?). But I am stuck at the error below, --- $ qemu-i386 -bsd freebsd hello Unable to load interpreter --- Any thoughts? 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] [help] QEMUFile's format
On Fri, Dec 23, 2011 at 01:32:50PM +0800, Shu Ming wrote: Do you mean the file format? qcow2, qed, raw? Or the content layout in the file image? On 2011-12-23 13:17, ¤終於aware wrote: Hi, Is anyone clear about the format of qemu file for savevm or loadvm? ^^ savevm requires image's format to be qcow2. You can check http://en.wikipedia.org/wiki/Qcow for more information. 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] [help] QEMUFile's format
savevm requires image's format to be qcow2. You can check http://en.wikipedia.org/wiki/Qcow for more information. Plus this, http://www.linux-kvm.org/wiki/images/6/63/2011-forum-qcow2.pdf 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] Do vm snapshot feature exist in qemu as in VMware
On Tue, Dec 20, 2011 at 06:55:19PM +0800, ¤終於aware wrote: Hi, how to save the current state of the running vm as a file and restore the last running state later by using the file as a arg of qemu cmd line? You can see http://en.wikibooks.org/wiki/QEMU/Monitor , search savevm and loadvm. 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] Do vm snapshot feature exist in qemu as in VMware
On Tue, Dec 20, 2011 at 06:55:19PM +0800, ¤終於aware wrote: Hi, how to save the current state of the running vm as a file and restore the last running state later by using the file as a arg of qemu cmd line? BTW, make sure your root file system's format support snapshot. For example, if you have a ext2 root file system rootfs.ext2, convert it to qcow2 format by using qemu-img. $ qemu-img convert -O qcow2 rootfs.ext2 rootfs.qcow2 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] linux-user: Fix 32-on-64 mmap for x86_64
This patch is actually wrong and we should rather make proper -R values the default instead of relying on MAP_32BIT. I don't understand what make proper -R values means. Where/how we can apply -R? Please see my other mail about this: http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg01697.html Ah, -R should mean -R size reserve size bytes for guest virtual address space 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] [PATCH v2] linux-user: Fix 32-on-64 mmap for x86_64
This patch is actually wrong and we should rather make proper -R values the default instead of relying on MAP_32BIT. I don't understand what make proper -R values means. Where/how we can apply -R? 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] Problem editing wiki page in wiki.qemu.org
Your current IP address is 127.0.0.1, and the block ID is #132. +1. :) 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] replace all strdup() with g_strdup()
Hi, You can check http://wiki.qemu.org/Contribute/SubmitAPatch to see how to send patch to qemu-devel. :) 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] linux-user/main.c: Add option to user-mode emulation so that user can specify log file name
Hi Riku, Ping? This patch still applies TOT. 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] The reason behind block linking constraint? (Cont.)
On Thu, Dec 15, 2011 at 03:53:10PM +0800, Zhi Yong Wu wrote: I have one related question. If you build one new kernel image and initrd from Linus' kernel git tree, and don't modify qemu, can it work fine? I don't understand what's your point. Unmodified QEMU should boot linux, 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] some questions about g_malloc in qemu
I am not sure whether it is need to check the return of g_malloc in qemu ? I think not, that's why you use g_malloc as a wrapper. 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 questions about g_malloc in qemu
Hi, I found this in HACKING: Please note that NULL check for the g_malloc result is redundant and that g_malloc() call with zero size is not allowed. 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 questions about g_malloc in qemu
Maybe there is insufficient memory, the return is error, Do we need to check the return ? It'll abort if there is not enough memory. http://mail.gnome.org/archives/gtk-app-devel-list/2003-September/msg00260.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] The reason behind block linking constraint? (Cont.)
Yes. Did you build one bzImage based on Linus kernel git tree, and then use unmodified QEMU to boot it? Can it succeed to start up? Current buildroot (snapshot version) build linux 3.x by default, and unmodified QEMU can boot 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
Re: [Qemu-devel] QEMU TB Unlinking due to interrupt.
On Tue, Dec 13, 2011 at 08:29:50PM -0500, Xin Tong wrote: QEMU performs a recursive unchaining on the current executing tb when a timer fires. This timer is set by setitimer in the qemu-timer.c. You mean dynticks_start_timer? This is what I mean by interrupt pending. Of course, there are interrupts from emulated devices as well, but i do not know how that is set up, i.e. how tcg_handle_interrupt is called when the devices finishes some work. I hope you can enlighten me on that. I am not familiar with how QEMU deal with virtual devices. But AFAIK, virtual devices will register IRQ to APIC (hw/apic.c), APIC will call cpu_interrupt (cpu-all.h), which turns to call cpu_interrupt_handler. You can see cpu_interrupt_handler is assigned as tcg_handle_interrupt in exec.c. tcg_handle_interrupt raise env's interrupt_request, and leave cpu_exec to check env's interrupt_request. 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] The reason behind block linking constraint? (Cont.)
Hi all,
I want to continue the discussion about the cross page constraint on block
linking [1][2]. Max explained to me that if we link TBs belong different guest
pages, then QEMU might crash when the memory mapping is changed by tlb_set_page
(exec.c). Memory mapping changes may be the result of a page swapping or a task
switch. My final goal is to understand why we need to put such constraint on
block linking completely. And if we remove the constraint, in what situation
the QEMU crash. The reason that we (our QEMU + LLVM project [3]) want to
investigate this is we have a few optimizations which would like to remove cross
page constraint if possible, say trace building, for example.
I use two linux image: (A) is downloaded from the QEMU website, and (B) is
built by using buildroot [4]. I modify QEMU 1.0, only remove the if-else
statement in function gen_goto_tb (target-i386/translate.c). So it becomes,
static inline void gen_goto_tb(DisasContext *s, int tb_num, target_ulong eip)
{
TranslationBlock *tb;
target_ulong pc;
pc = s-cs_base + eip;
tb = s-tb;
/* leave only the if branch */
tcg_gen_goto_tb(tb_num);
gen_jmp_im(eip);
tcg_gen_exit_tb((tcg_target_long)tb + tb_num);
}
Below is how I use buildroot to build the kernel image and root file system.
---
$ wget
http://buildroot.uclibc.org/downloads/snapshots/buildroot-snapshot.tar.bz2
$ tar xvf buildroot-snapshot.tar.bz2; cd buildroot
# I leave the default config alone
$ make qemu_x86_defconfig; make menuconfig; make
$ cd output/images/
$ qemu-system-i386 -kernel bzImage -hda rootfs.ext2 -vnc 0.0.0.0:1
---
I get a kernel panic while booting (A), but (B) *works fine*. I am pretty sure
they both call tlb_set_page. Is it because (B) calls tlb_set_page but doesn't
modify the same tlb entry or other reasons so that it works fine even we remove
the cross page constraint from block linking?
Any comment appreciated.
Regards,
chenwj
[1] http://lists.nongnu.org/archive/html/qemu-devel/2011-08/msg02249.html
[2] https://lists.gnu.org/archive/html/qemu-devel/2011-09/msg03065.html
[3] http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg03420.html
[4] http://buildroot.uclibc.org/
--
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 TB Unlinking due to interrupt.
1. some other tbs being invalidated. 2. interrrupt pending Could you point out interrrupt pending means where? I'd like to take a look, 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] SMP cpu_index error on X86_64
Hi, Sorry I cann't help here. Just to be curious. Are you working in PQEMU project? 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: Remove redundant declarations of TCG_TARGET_REG_BITS
On Wed, Dec 07, 2011 at 11:31:46PM +0100, Stefan Weil wrote: TCG_TARGET_REG_BITS is declared in tcg.h for all TCG targets. Just want to make sure. When we talk about target in TCG, that _always_ means the host, 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] Improve QEMU performance with LLVM codegen and other techniques
Hi Max, If your code is available online I can try it myself, the question is where is it hosted then. If not, then link to kernel binary and qemu exec trace would help me to start. Personally, I really want to make our work public, but I am not the decision maker. I'll push it toward open source however. ?..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 which turns out should be function check_timer (arch/i386/kernel/io_apic.c). I If it hangs inside QEMU itself then you may try to backport commit 4f61927a41a098d06e642ffdea5fc285dc3a0e6b that fixes infinite loop caused by hpet interrupt probing. 狢 don't understand. What it hangs inside QEMU itself supposed to mean? QEMU doesn't execute guest code doing something for itself vs. QEMU executes guest code in loop checking for something that doesn't happen. I'm talking about the first case. They may be distinguished from e.g. guest debugger connected to QEMU's gdbstub -- in the former case it cannot break guest execution by ^C. It turns out this is our IBTC optimization problem [1]. The IBTC should take cross page boundary constraint into consideration as block linking does (at least in QEMU current design) [2]. As I said before, we have two code caches in our framework: one for basic block, the other for trace. I forgot to turn off trace's IBTC optimization as it doesn't consider cross page boundary right now. As a workaround, we return to QEMU (dispatcher) while doing IBTC lookup, and the problem I mentioned disappeared. Sometimes I feel I am chaseing a ghost when debug our system. ;-) [1] http://lists.gnu.org/archive/html/qemu-devel/2011-08/msg01424.html [2] http://lists.nongnu.org/archive/html/qemu-devel/2011-08/msg02249.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] Improve QEMU performance with LLVM codegen and other techniques
If you want to be more exotic (minix found a lot of bugs for me back in the day!) you can try the os zoo: http://www.oszoo.org/ The website seems down? 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] Improve QEMU performance with LLVM codegen and other techniques
We ask TCG to disassemble the guest binary where the trace beginning with _again_ to get a set of TCG blocks, then sent them to the LLVM translator. So you have two TCG backends? One to generate real host code and one that goes into your LLVM generator? Ah..., I should say we ask QEMU frontend to disassemble the guest binary to TCG 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
Re: [Qemu-devel] Improve QEMU performance with LLVM codegen and other techniques
3. Then a trace composed of TCG blocks is sent to a LLVM translator. The translator generates the host binary for the trace into a LLVM code cache, and patch the I don't fully understand this part. Do you disassemble the x86 blob that TCG emitted? We ask TCG to disassemble the guest binary where the trace beginning with _again_ to get a set of TCG blocks, then sent them to the LLVM translator. the moment (make the situation simpler), I think we still don't have to check the blocks' hflags and segment descriptors in the trace to see if they match. Yeah. You only need to be sync'ed with the invalidation then. And make sure you patch the TB atomically, so you don't have a separate thread accidentally run half your code and half the old code. Sync'ed with the invalidation means tb_flush, cpu_unlink and tb_phys_invalidate? 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] Improve QEMU performance with LLVM codegen and other techniques
Hi Peter,
1. cpu_unlink_tb (exec.c)
This function is broken even for pure TCG -- we know it has a race condition.
As I said on IRC, I think that the right thing to do is to start
by overhauling the current TCG code so that it is:
(a) properly multithreaded (b) race condition free (c) well documented
(d) clean code
Then you have a firm foundation you can use as a basis for the LLVM
integration (and in the course of doing this overhaul you'll have
figured out enough of how the current code works to be clear about
where hooks for invalidating your traces need to go).
I must say I totally agree with you on overhauling the current TCG code. But
my boss might have no such patient on this. ;) If there is a plan out there,
I'll
be very happy to join in.
I read the thread talking about the broken tb_unlink [1], and I'm surprised
that tb_unlink is broken even under single-threaded mode and system mode. You
mentioned (b) could be the IO thread in [1]. I think we don't enable IO thread
in system mode right now. My concern is if I spot _all_ place/situation that I
need to break the link between block and trace.
The big problem is debugging.
Yes. In this sort of hotspot based design it's very easy to end up
with bugs that are intermittent or painful to reproduce and where
you have very little clue about which version of the code for which
address ended up misgenerated (since timing issues mean that what
code is recompiled and when it is inserted will vary from run to
run). Being able to conveniently get rid of some of this nondeterminism
is vital for tracking down what actually goes wrong.
Misgenerated code might not be an issue now since we have tested our framework
in LLVM-only mode. I think the problem still is about the link/unlink stuff.
The first problem I have while lowering the threshold is the broken one generate
a few traces (2, actually) that a work one doesn't. When boot the linux image
downloaded from the QEMU website, the system hangs on the booting process (see
attach if you're interested). Simply put, the system hangs after printing
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
which turns out should be function check_timer (arch/i386/kernel/io_apic.c). I
am not a Linux kernel expert and have no idea how to solve this. The culprit
traces beginning with 0xc0b8 and 0xc0d7. Here is their corresponding
guest binary.
IN:
0xc0b8: add0xc04fa798,%eax
0xc0be: mov(%eax),%eax
0xc0c0: ret
IN:
0xc0d7: mov$0x108,%eax
0xc0dc: call 0xc0b8
I compile the linux kernel with debug info and without inline function, then
objdump vmlinux to see what the source code might be. I guess because
linux-0.2.img
has other stuff besides vmlinux (kernel image), the addresses above can only be
used as an approximation or even useless. I only find one spot having the same
code sequence (I believe) as 0xc0b8 but can't find the other one so far.
See below,
static inline unsigned int readl(const volatile void __iomem *addr)
{
return *(volatile unsigned int __force *) addr;
c0214a90: 03 05 44 56 4f c0 add0xc04f5644,%eax
c0214a96: 8b 00 mov(%eax),%eax
#define FSEC_TO_USEC (10UL)
int hpet_readl(unsigned long a)
{
return readl(hpet_virt_address + a);
}
c0214a98: c3 ret
This is the whole story so far. :-) Any comment are welcome!
[1] http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg02447.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] Improve QEMU performance with LLVM codegen and other techniques
Hi, Stefan It would be interesting to use an optimized interpreter instead of TCG, then go to LLVM for hot traces. This is more HotSpot-like with the idea being that the interpreter runs through initialization and rarely executed code without a translation overhead. For the hot paths LLVM kicks in and high-quality translated code is executed. Not sure if it's doable. I can only tell you we rely on QEMU frontend to disassemble guest binary into TCG IR, then translate TCG IR into LLVM IR. And talk about the translation overhead, the time QEMU frontend spend is negligible. 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] Improve QEMU performance with LLVM codegen and other techniques
The IO thread is always enabled in QEMU these days. We use QEMU 0.13. I think IO thread is not enabled by default. 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] Improve QEMU performance with LLVM codegen and other techniques
Hi Alex, Very cool! I was thinking about this for a while myself now. It's especially appealing these days since you can do the hotspot optimization in a separate thread :). Especially in system mode, you also need to flush when tb_flush() is called though. And you have to make sure to match hflags and segment descriptors for the links - otherwise you might end up connecting TBs from different processes :). I'll check the tb_flush again. IIRC, we make the code cache big enough so that there is no need to flush the code cache. But I think we still need to deal with it in the end. The block linking is done by QEMU and we leave it alone. But I don't know QEMU ever does hflags and segment descriptors check before doing block linking. Could you point it out? Anyway, here is how we form trace from a set of basic blocks. 1. We insert instrumented code at the beginning of each TCG block to collect how many times this block being executed. 2. When a block's execution time, say block A, reaches a pre-defined threshold, we follow the run time execution path to collect block B followed A and so on to form a trace. This approach is called NET (Next-Executing Tail) [1]. 3. Then a trace composed of TCG blocks is sent to a LLVM translator. The translator generates the host binary for the trace into a LLVM code cache, and patch the beginning of block A (in QEMU code cache) so that anyone executing block A will jump to the corresponding trace and execute. Above is block to trace link. I think there is no need to do hflags and segment descriptors check, right? Although I set the trace length to one basic block at the moment (make the situation simpler), I think we still don't have to check the blocks' hflags and segment descriptors in the trace to see if they match. successfully, then login and run some benchmark on it. As a very first step, we make a very high threshold on trace building. In other words, a basic block must be executed *many* time to trigger the trace building process. Then we lower the threshold a bit at a time to see how things work. When something goes wrong, we might get kernel panic or the system hangs at some point on the booting process. I have no idea on how to solve this kind of problem. So I'd like to seek for help/experience/suggestion on the mailing list. I just hope I make the whole situation clear to you. I don't see any better approach to debugging this than the one you're already taking. Try to run as many workloads as you can and see if they break :). Oh and always make the optimization optional, so that you can narrow it down to it and know you didn't hit a generic QEMU bug. You mean make the trace optimization optional? We have tested our framework in LLVM-only mode. which means we replace TCG with LLVM entirely. It's _very_ slow but works. What the generic QEMU bug is? We use QEMU 0.13 and just rely on its emulation part right now. Does recent version fix major bugs in the emulation engine? Thanks for your advices. :-) [1] http://www.cs.virginia.edu/kim/docs/micro05.pdf 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] [ICON] My name is Q, Q Emu!
* The nostril is Yin-shaped; the matching Yang would be KVM or Xen. :) Hey, you know Yin-Yang! XD But, there should be a Yang spot in the Yin-shape. I'm just too picky. :p http://en.wikipedia.org/wiki/Taiji 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] Improve QEMU performance with LLVM codegen and other techniques
Hi all, Our team are working on a project similar to llvm-qemu [1], which is also based on QEMU and LLVM. Current status is the process mode works fine [2], and we're moving forward to system mode. Let me briefly introduce our framework here and state what problem we encounter. What we do is translating TCG IR into LLVM IR and let LLVM JIT do the codegen. In our framework, we have both TCG and LLVM codegen capacity. For short-running application, TCG's code quality is good enough; LLVM codegen is for long-running application on the other hand. We have two code cache in our framework, one is the original QEMU code cache (for basic block) and the other is LLVM code cache (for trace). The concept of trace is the same as the super-blocks as mentioned in the discussion thread [3], which is composed of a set of basic blocks. The goal is to enlarge the optimization scope and hope the code quality of trace is better than the basic block's. Here is the overview of our framework. QEMU code cacheLLVM code cache (block)(trace) bb1 trace1 In our framework, if we find a basic block (bb1) is hot enough (i.e., being executed many times), we start building a trace (beginning with bb1) and let LLVM do the codegen. We place the optimized code in the LLVM code cache, and patch the head of bb1 so that anyone executing bb1 will jump to trace1 directly. Since we're moving toward system mode, we have to consider situations where unlinking is needed. Block linking done by QEMU itself and we leave block unlinking to it. The problem is when/where to break the link between block and trace. I can only spot two places we should break the block - trace link so far [4]. I don't know if I spot them all or I miss something else. 1. cpu_unlink_tb (exec.c) 2. tb_phys_invalidate (exec.c) The big problem is debugging. We test our system by using images downloaded from the website [5]. Basically, we want to see an operating system being booted successfully, then login and run some benchmark on it. As a very first step, we make a very high threshold on trace building. In other words, a basic block must be executed *many* time to trigger the trace building process. Then we lower the threshold a bit at a time to see how things work. When something goes wrong, we might get kernel panic or the system hangs at some point on the booting process. I have no idea on how to solve this kind of problem. So I'd like to seek for help/experience/suggestion on the mailing list. I just hope I make the whole situation clear to you. Thanks! [1] http://code.google.com/p/llvm-qemu/ [2] I have to admit we only test our framework with SPEC2006 benchmark, not with _real_ applications. [3] http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-April/013689.html [4] http://lists.gnu.org/archive/html/qemu-devel/2011-09/msg03643.html [5] http://wiki.qemu.org/Download 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] self modifying code
On Fri, Nov 25, 2011 at 08:15:33AM -0500, Xin Tong wrote: I have 2 questions regarding self modifying code on qemu. 1. how does qemu detect self modifying code. 2. does qemu flush the code cache completely or partially when self modifying code is encountered ? Thanks Xin How QEMU handle self-modifying code? http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00556.html Q1. See those two calling sequences. Q2. No. 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] self modifying code
On Fri, Nov 25, 2011 at 08:15:33AM -0500, Xin Tong wrote: I have 2 questions regarding self modifying code on qemu. 1. how does qemu detect self modifying code. 2. does qemu flush the code cache completely or partially when self modifying code is encountered ? I mean qemu does NOT the entire code cache. 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] TB chaining
On Thu, Nov 24, 2011 at 08:54:36PM -0500, Xin Tong wrote:
I came back to the block chaining code. This code is still not very
clear to me. Here we are linking tb_next - tb. jmp_next of the tb
contains the next tbs it will jump to. why are we checking the
!tb-jmp_next[n], but not !tb_next-jmp_next[n] ?
static inline void tb_add_jump(TranslationBlock *tb, int n,
TranslationBlock *tb_next)
{
if (!tb-jmp_next[n]) {
/* patch the native jump address */
tb_set_jmp_target(tb, n, (unsigned long)tb_next-tc_ptr);
/* add in TB jmp circular list */
tb-jmp_next[n] = tb_next-jmp_first;
tb_next-jmp_first = (TranslationBlock *)((long)(tb) | (n));
}
}
Maybe I talked about TB chaining wrong before. The variable names in
QEMU could be misleading. next_tb and tb_next are _different_ things.
Let's see cpu_exec (cpu-exec.c) which calls tb_add_jump first.
// TB chaining direction: next_tb - tb
if (next_tb != 0 tb-page_addr[1] == -1) {
tb_add_jump((TranslationBlock *)(next_tb ~3), next_tb 3, tb);
}
Then let's see tb_add_jump.
// TB chaining direction: tb - tb_next
static inline void tb_add_jump(TranslationBlock *tb, int n,
TranslationBlock *tb_next)
{
if (!tb-jmp_next[n]) {
/* patch the native jump address */
tb_set_jmp_target(tb, n, (unsigned long)tb_next-tc_ptr);
/* add in TB jmp circular list */
tb-jmp_next[n] = tb_next-jmp_first;
tb_next-jmp_first = (TranslationBlock *)((long)(tb) | (n));
}
}
QEMU uses jmp_next and jmp_first to record the TB chaining status. I
think visual presentation can help you understand how this is working.
Here you go,
http://people.cs.nctu.edu.tw/~chenwj/slide/QEMU/QEMU%20-%20block%20chaining.ppt
P.S. In case you know chinese, you can see the articles on
http://www.hellogcc.org/ (search tag 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] oprofile on qemu
On Tue, Nov 22, 2011 at 08:23:32AM -0500, Xin Tong wrote: Is there a way to profile QEMU's code cache ? What do you try to profile? The execution time in the code cache? P.S. The subject is a little misleading. Oprofile is a tool. Do you specify you want use Oprofile only? 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] linux-user crashing in multi-threaded programs
On Mon, Nov 21, 2011 at 10:11:37AM +, Peter Maydell wrote: On 21 November 2011 10:07, Alexander Graf ag...@suse.de wrote: On 21.11.2011, at 10:59, Peter Maydell wrote: You can hit this bug even single-threaded or in system mode: it's just that aggressively multi-threaded user apps are the easiest way to trigger it. So I don't think we can ever use the tb-unlinking code safely. Not sure I understand. I thought it's a race between multiple threads trying to chain/unchain TBs at the same time? How can that happen in system or single-threaded mode? It's a race between (a) a thread executing code and (b) any other thread or signal handler that calls cpu_exit(). So (b) can be the IO thread, or the linux-user host_signal_handler(). Would it be a good idea to write this as a comment about cpu_unlink_tb? 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 6/6] LICENSE: There is no libqemu.a anymore
From: Chen Wei-Ren che...@iis.sinica.edu.tw Remove statement about libqemu.a from LICENSE. Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw --- LICENSE |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/LICENSE b/LICENSE index cbd92c0..acae9a3 100644 --- a/LICENSE +++ b/LICENSE @@ -6,9 +6,7 @@ The following points clarify the QEMU license: GNU General Public License. Hence each source file contains its own licensing information. -In particular, the QEMU virtual CPU core library (libqemu.a) is -released under the GNU Lesser General Public License. Many hardware -device emulation sources are released under the BSD license. +Many hardware device emulation sources are released under the BSD license. 3) The Tiny Code Generator (TCG) is released under the BSD license (see license headers in files). -- 1.7.3.4
[Qemu-devel] [PATCH v3 1/6] tests/Makefile: Remove qruncom target
From: Chen Wei-Ren che...@iis.sinica.edu.tw Remove qruncom target from the Makefile file. Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw --- tests/Makefile |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/tests/Makefile b/tests/Makefile index 430e0c1..15e36a2 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -115,12 +115,6 @@ speed: sha1 sha1-i386 time ./sha1 time $(QEMU) ./sha1-i386 -# broken test -# NOTE: -fomit-frame-pointer is currently needed : this is a bug in libqemu -qruncom: qruncom.c ../ioport-user.c ../i386-user/libqemu.a - $(CC) $(CFLAGS) -fomit-frame-pointer $(LDFLAGS) -I../target-i386 -I.. -I../i386-user -I../fpu \ - -o $@ $(filter %.c, $^) -L../i386-user -lqemu -lm - # arm test hello-arm: hello-arm.o arm-linux-ld -o $@ $ -- 1.7.3.4
[Qemu-devel] [PATCH v3 2/6] tests/qruncom.c: Remove libqemu.a example
From: Chen Wei-Ren che...@iis.sinica.edu.tw
Remove libqemu example since libqemu.a is not available anymore.
Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw
---
tests/qruncom.c | 284 ---
1 files changed, 0 insertions(+), 284 deletions(-)
delete mode 100644 tests/qruncom.c
diff --git a/tests/qruncom.c b/tests/qruncom.c
deleted file mode 100644
index 2e93aaf..000
--- a/tests/qruncom.c
+++ /dev/null
@@ -1,284 +0,0 @@
-/*
- * Example of use of user mode libqemu: launch a basic .com DOS
- * executable
- */
-#include stdlib.h
-#include stdio.h
-#include string.h
-#include inttypes.h
-#include unistd.h
-#include fcntl.h
-#include sys/mman.h
-#include signal.h
-#include malloc.h
-
-#include cpu.h
-
-//#define SIGTEST
-
-int cpu_get_pic_interrupt(CPUState *env)
-{
-return -1;
-}
-
-uint64_t cpu_get_tsc(CPUState *env)
-{
-return 0;
-}
-
-static void set_gate(void *ptr, unsigned int type, unsigned int dpl,
- unsigned long addr, unsigned int sel)
-{
-unsigned int e1, e2;
-e1 = (addr 0x) | (sel 16);
-e2 = (addr 0x) | 0x8000 | (dpl 13) | (type 8);
-stl((uint8_t *)ptr, e1);
-stl((uint8_t *)ptr + 4, e2);
-}
-
-uint64_t idt_table[256];
-
-/* only dpl matters as we do only user space emulation */
-static void set_idt(int n, unsigned int dpl)
-{
-set_gate(idt_table + n, 0, dpl, 0, 0);
-}
-
-void g_free(void *ptr)
-{
-free(ptr);
-}
-
-void *g_malloc(size_t size)
-{
-return malloc(size);
-}
-
-void *g_malloc0(size_t size)
-{
-void *ptr;
-ptr = g_malloc(size);
-if (!ptr)
-return NULL;
-memset(ptr, 0, size);
-return ptr;
-}
-
-void *qemu_vmalloc(size_t size)
-{
-return memalign(4096, size);
-}
-
-void qemu_vfree(void *ptr)
-{
-free(ptr);
-}
-
-void qemu_printf(const char *fmt, ...)
-{
-va_list ap;
-va_start(ap, fmt);
-vprintf(fmt, ap);
-va_end(ap);
-}
-
-/* XXX: this is a bug in helper2.c */
-int errno;
-
-/**/
-
-#define COM_BASE_ADDR0x10100
-
-static void usage(void)
-{
-printf(qruncom version 0.1 (c) 2003 Fabrice Bellard\n
- usage: qruncom file.com\n
- user mode libqemu demo: run simple .com DOS executables\n);
-exit(1);
-}
-
-static inline uint8_t *seg_to_linear(unsigned int seg, unsigned int reg)
-{
-return (uint8_t *)((seg 4) + (reg 0x));
-}
-
-static inline void pushw(CPUState *env, int val)
-{
-env-regs[R_ESP] = (env-regs[R_ESP] ~0x) | ((env-regs[R_ESP] - 2)
0x);
-*(uint16_t *)seg_to_linear(env-segs[R_SS].selector, env-regs[R_ESP]) =
val;
-}
-
-static void host_segv_handler(int host_signum, siginfo_t *info,
- void *puc)
-{
-if (cpu_signal_handler(host_signum, info, puc)) {
-return;
-}
-abort();
-}
-
-int main(int argc, char **argv)
-{
-uint8_t *vm86_mem;
-const char *filename;
-int fd, ret, seg;
-CPUState *env;
-
-if (argc != 2)
-usage();
-filename = argv[1];
-
-vm86_mem = mmap((void *)0x, 0x11,
-PROT_WRITE | PROT_READ | PROT_EXEC,
-MAP_FIXED | MAP_ANON | MAP_PRIVATE, -1, 0);
-if (vm86_mem == MAP_FAILED) {
-perror(mmap);
-exit(1);
-}
-
-/* load the MSDOS .com executable */
-fd = open(filename, O_RDONLY);
-if (fd 0) {
-perror(filename);
-exit(1);
-}
-ret = read(fd, vm86_mem + COM_BASE_ADDR, 65536 - 256);
-if (ret 0) {
-perror(read);
-exit(1);
-}
-close(fd);
-
-/* install exception handler for CPU emulator */
-{
-struct sigaction act;
-
-sigfillset(act.sa_mask);
-act.sa_flags = SA_SIGINFO;
-//act.sa_flags |= SA_ONSTACK;
-
-act.sa_sigaction = host_segv_handler;
-sigaction(SIGSEGV, act, NULL);
-sigaction(SIGBUS, act, NULL);
-}
-
-//cpu_set_log(CPU_LOG_TB_IN_ASM | CPU_LOG_TB_OUT_ASM | CPU_LOG_EXEC);
-
-env = cpu_init(qemu32);
-
-cpu_x86_set_cpl(env, 3);
-
-env-cr[0] = CR0_PG_MASK | CR0_WP_MASK | CR0_PE_MASK;
-/* NOTE: hflags duplicates some of the virtual CPU state */
-env-hflags |= HF_PE_MASK | VM_MASK;
-
-/* flags setup : we activate the IRQs by default as in user
- mode. We also activate the VM86 flag to run DOS code */
-env-eflags |= IF_MASK | VM_MASK;
-
-/* init basic registers */
-env-eip = 0x100;
-env-regs[R_ESP] = 0xfffe;
-seg = (COM_BASE_ADDR - 0x100) 4;
-
-cpu_x86_load_seg_cache(env, R_CS, seg,
- (seg 4), 0x, 0);
-cpu_x86_load_seg_cache(env, R_SS, seg,
- (seg 4), 0x, 0);
-cpu_x86_load_seg_cache(env, R_DS, seg,
- (seg 4), 0x, 0);
-cpu_x86_load_seg_cache(env, R_ES, seg,
- (seg 4), 0x, 0);
-cpu_x86_load_seg_cache(env,
[Qemu-devel] [PATCH v3 0/6] Remove libqemu related stuff from QEMU source tree
From: Chen Wei-Ren che...@iis.sinica.edu.tw According to [1], libqemu is not available anymore. Remove libqemu related stuff from QEMU source tree. [1] http://www.mail-archive.com/address@hidden/msg49809.html v2: - Remove entry qruncom.c from 3 Regression Tests in qemu-tech.texi. - Undo the deletion of common-obj-y. Only remove libqemu_common.a from the comment. v3: - Change tests/Makefile first before removing tests/qruncom.c. - Only remove out-of-date comment about libqemu.a from Makefile.target, leave manually inserted dependencie alone. Chen Wei-Ren (6): tests/Makefile: Remove qruncom target tests/qruncom.c: Remove libqemu.a example qemu-tech.texi: Remove libqemu related stuff from the document Makefile.target: Remove out of date comment Makefile.objs: Remove libqemu_common.a from the comment LICENSE: There is no libqemu.a anymore LICENSE |4 +- Makefile.objs |7 +- Makefile.target |2 - qemu-tech.texi | 10 -- tests/Makefile |6 - tests/qruncom.c | 284 --- 6 files changed, 4 insertions(+), 309 deletions(-) delete mode 100644 tests/qruncom.c -- 1.7.3.4
Re: [Qemu-devel] [ANNOUNCE] QEMU 1.0-rc1
Hi, Anthony On behalf of the QEMU Team, I'd like to announce the availability of QEMU 1.0, release candidate 2. This is the second release candidate for the 1.0 release. This is not intended for production use but rather for testing. The mail subject should be QEMU 1.0-rc2 not QEMU 1.0-rc1, then? :-) 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] [ICON] QEMU Mascot Contest v.2
Hi, Stefan Thanks, I have added your mascots to my icon / mascot collection (http://qemu.weilnetz.de/icon/), also in different standard sizes. There is still a lot of unused space around the image, therefore scaling of the svg file does not look pretty. By fixing the document properties in Inkscape, you can reduce the image size and remove that unneeded space. Hope this what you want, http://people.cs.nctu.edu.tw/~chenwj/slide/QEMU/QEMU_Mascot_no_text.svg http://people.cs.nctu.edu.tw/~chenwj/slide/QEMU/QEMU_Mascot_embody_text.svg http://people.cs.nctu.edu.tw/~chenwj/slide/QEMU/QEMU_Mascot_text_right.svg 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] [ICON] QEMU Mascot Contest v.2
Which character fonts did you use for 'Q' and for 'emu' in QEMU_Mascot_embody_text.svg? Andalus for 'Q' and Berlin Sans FB for 'emu'. It might be interesting to try 'emu' rotated by about -60 degree (in the direction of the egg shaped body). This direction? http://people.cs.nctu.edu.tw/~chenwj/slide/QEMU/QEMU_Mascot_embody_text_rotate.svg 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] [ICON] QEMU Mascot Contest
Hi, all I am not a good painter or an artist, but here you go http://people.cs.nctu.edu.tw/~chenwj/slide/QEMU/QEMU_Mascot.png Let me know what 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] [ICON] QEMU Mascot Contest
Neat idea to combine the emu with the Q shape. It would be nice to find a high resolution emu, this one is quite pixelated. See my link from the other thread: http://commons.wikimedia.org/wiki/File:Emu_(PSF).png Actually, I borrow that picture and do some cut/paste. ;-) I am a M$ user, and as I said I am not good at such things. If you guys know what free tool available I can use on M$, tell me. Or you can just take my idea and make it looks better. 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] [ICON] QEMU Mascot Contest v.2
You might use Inkscape for M$ from http://inkscape.org/download/ and the highest resolution image from Wikipedia (http://upload.wikimedia.org/wikipedia/commons/7/7d/Emu_%28PSF%29.png). I have tried my best. :-) http://people.cs.nctu.edu.tw/~chenwj/slide/QEMU/QEMU_Mascot.svg 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 4/6 v2] Makefile.target: Remove libqemu target
From: Chen Wei-Ren che...@iis.sinica.edu.tw Remove libqemu target from Makefile.target. I have ran the following test: - process mode: linux-user-test-0.3 - system mode: - arm-test-0.2.tar.gz - minix204.tar.bz2 - linux-0.2.img.bz2 Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw --- Makefile.target |8 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/Makefile.target b/Makefile.target index a111521..d1f7993 100644 --- a/Makefile.target +++ b/Makefile.target @@ -92,14 +92,6 @@ tci-dis.o: QEMU_CFLAGS += -I$(SRC_PATH)/tcg -I$(SRC_PATH)/tcg/tci $(libobj-y): $(GENERATED_HEADERS) -# libqemu - -translate.o: translate.c cpu.h - -translate-all.o: translate-all.c cpu.h - -tcg/tcg.o: cpu.h - # HELPER_CFLAGS is used for all the code compiled with static register # variables op_helper.o ldst_helper.o user-exec.o: QEMU_CFLAGS += $(HELPER_CFLAGS) -- 1.7.3.4
[Qemu-devel] [PATCH 6/6 v2] LICENSE: There is no libqemu.a anymore
From: Chen Wei-Ren che...@iis.sinica.edu.tw Remove statement about libqemu.a from LICENSE. Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw --- LICENSE |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/LICENSE b/LICENSE index cbd92c0..acae9a3 100644 --- a/LICENSE +++ b/LICENSE @@ -6,9 +6,7 @@ The following points clarify the QEMU license: GNU General Public License. Hence each source file contains its own licensing information. -In particular, the QEMU virtual CPU core library (libqemu.a) is -released under the GNU Lesser General Public License. Many hardware -device emulation sources are released under the BSD license. +Many hardware device emulation sources are released under the BSD license. 3) The Tiny Code Generator (TCG) is released under the BSD license (see license headers in files). -- 1.7.3.4
[Qemu-devel] [PATCH 1/6 v2] tests/qruncom.c: Remove libqemu.a example
From: Chen Wei-Ren che...@iis.sinica.edu.tw
Remove libqemu example since libqemu.a is not available anymore.
Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw
---
tests/qruncom.c | 284 ---
1 files changed, 0 insertions(+), 284 deletions(-)
delete mode 100644 tests/qruncom.c
diff --git a/tests/qruncom.c b/tests/qruncom.c
deleted file mode 100644
index 2e93aaf..000
--- a/tests/qruncom.c
+++ /dev/null
@@ -1,284 +0,0 @@
-/*
- * Example of use of user mode libqemu: launch a basic .com DOS
- * executable
- */
-#include stdlib.h
-#include stdio.h
-#include string.h
-#include inttypes.h
-#include unistd.h
-#include fcntl.h
-#include sys/mman.h
-#include signal.h
-#include malloc.h
-
-#include cpu.h
-
-//#define SIGTEST
-
-int cpu_get_pic_interrupt(CPUState *env)
-{
-return -1;
-}
-
-uint64_t cpu_get_tsc(CPUState *env)
-{
-return 0;
-}
-
-static void set_gate(void *ptr, unsigned int type, unsigned int dpl,
- unsigned long addr, unsigned int sel)
-{
-unsigned int e1, e2;
-e1 = (addr 0x) | (sel 16);
-e2 = (addr 0x) | 0x8000 | (dpl 13) | (type 8);
-stl((uint8_t *)ptr, e1);
-stl((uint8_t *)ptr + 4, e2);
-}
-
-uint64_t idt_table[256];
-
-/* only dpl matters as we do only user space emulation */
-static void set_idt(int n, unsigned int dpl)
-{
-set_gate(idt_table + n, 0, dpl, 0, 0);
-}
-
-void g_free(void *ptr)
-{
-free(ptr);
-}
-
-void *g_malloc(size_t size)
-{
-return malloc(size);
-}
-
-void *g_malloc0(size_t size)
-{
-void *ptr;
-ptr = g_malloc(size);
-if (!ptr)
-return NULL;
-memset(ptr, 0, size);
-return ptr;
-}
-
-void *qemu_vmalloc(size_t size)
-{
-return memalign(4096, size);
-}
-
-void qemu_vfree(void *ptr)
-{
-free(ptr);
-}
-
-void qemu_printf(const char *fmt, ...)
-{
-va_list ap;
-va_start(ap, fmt);
-vprintf(fmt, ap);
-va_end(ap);
-}
-
-/* XXX: this is a bug in helper2.c */
-int errno;
-
-/**/
-
-#define COM_BASE_ADDR0x10100
-
-static void usage(void)
-{
-printf(qruncom version 0.1 (c) 2003 Fabrice Bellard\n
- usage: qruncom file.com\n
- user mode libqemu demo: run simple .com DOS executables\n);
-exit(1);
-}
-
-static inline uint8_t *seg_to_linear(unsigned int seg, unsigned int reg)
-{
-return (uint8_t *)((seg 4) + (reg 0x));
-}
-
-static inline void pushw(CPUState *env, int val)
-{
-env-regs[R_ESP] = (env-regs[R_ESP] ~0x) | ((env-regs[R_ESP] - 2)
0x);
-*(uint16_t *)seg_to_linear(env-segs[R_SS].selector, env-regs[R_ESP]) =
val;
-}
-
-static void host_segv_handler(int host_signum, siginfo_t *info,
- void *puc)
-{
-if (cpu_signal_handler(host_signum, info, puc)) {
-return;
-}
-abort();
-}
-
-int main(int argc, char **argv)
-{
-uint8_t *vm86_mem;
-const char *filename;
-int fd, ret, seg;
-CPUState *env;
-
-if (argc != 2)
-usage();
-filename = argv[1];
-
-vm86_mem = mmap((void *)0x, 0x11,
-PROT_WRITE | PROT_READ | PROT_EXEC,
-MAP_FIXED | MAP_ANON | MAP_PRIVATE, -1, 0);
-if (vm86_mem == MAP_FAILED) {
-perror(mmap);
-exit(1);
-}
-
-/* load the MSDOS .com executable */
-fd = open(filename, O_RDONLY);
-if (fd 0) {
-perror(filename);
-exit(1);
-}
-ret = read(fd, vm86_mem + COM_BASE_ADDR, 65536 - 256);
-if (ret 0) {
-perror(read);
-exit(1);
-}
-close(fd);
-
-/* install exception handler for CPU emulator */
-{
-struct sigaction act;
-
-sigfillset(act.sa_mask);
-act.sa_flags = SA_SIGINFO;
-//act.sa_flags |= SA_ONSTACK;
-
-act.sa_sigaction = host_segv_handler;
-sigaction(SIGSEGV, act, NULL);
-sigaction(SIGBUS, act, NULL);
-}
-
-//cpu_set_log(CPU_LOG_TB_IN_ASM | CPU_LOG_TB_OUT_ASM | CPU_LOG_EXEC);
-
-env = cpu_init(qemu32);
-
-cpu_x86_set_cpl(env, 3);
-
-env-cr[0] = CR0_PG_MASK | CR0_WP_MASK | CR0_PE_MASK;
-/* NOTE: hflags duplicates some of the virtual CPU state */
-env-hflags |= HF_PE_MASK | VM_MASK;
-
-/* flags setup : we activate the IRQs by default as in user
- mode. We also activate the VM86 flag to run DOS code */
-env-eflags |= IF_MASK | VM_MASK;
-
-/* init basic registers */
-env-eip = 0x100;
-env-regs[R_ESP] = 0xfffe;
-seg = (COM_BASE_ADDR - 0x100) 4;
-
-cpu_x86_load_seg_cache(env, R_CS, seg,
- (seg 4), 0x, 0);
-cpu_x86_load_seg_cache(env, R_SS, seg,
- (seg 4), 0x, 0);
-cpu_x86_load_seg_cache(env, R_DS, seg,
- (seg 4), 0x, 0);
-cpu_x86_load_seg_cache(env, R_ES, seg,
- (seg 4), 0x, 0);
-cpu_x86_load_seg_cache(env,
[Qemu-devel] [PATCH 5/6 v2] Makefile.objs: Remove libqemu_common.a from the comment
From: Chen Wei-Ren che...@iis.sinica.edu.tw Remove libqemu_common.a from the comment. v1 - v2: Reverse the deletion of common-obj-y. Only remove libqemu_common.a from the comment. Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw --- Makefile.objs |7 +++ 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/Makefile.objs b/Makefile.objs index d7a6539..90afdfa 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -68,10 +68,9 @@ endif fsdev-obj-$(CONFIG_VIRTFS) += $(addprefix fsdev/, $(fsdev-nested-y)) ## -# libqemu_common.a: Target independent part of system emulation. The -# long term path is to suppress *all* target specific code in case of -# system emulation, i.e. a single QEMU executable should support all -# CPUs and machines. +# Target independent part of system emulation. The long term path is +# to suppress *all* target specific code in case of system emulation, +# i.e. a single QEMU executable should support all CPUs and machines. common-obj-y = $(block-obj-y) blockdev.o common-obj-y += $(net-obj-y) -- 1.7.3.4
[Qemu-devel] [PATCH 0/6 v2] Remove libqemu related stuff from QEMU source tree
From: Chen Wei-Ren che...@iis.sinica.edu.tw According to [1], libqemu is not available anymore. Remove libqemu related stuff from QEMU source tree. [1] http://www.mail-archive.com/address@hidden/msg49809.html Chen Wei-Ren (6): tests/qruncom.c: Remove libqemu.a example tests/Makefile: Remove qruncom target qemu-tech.texi: Remove libqemu related stuff from the document Makefile.target: Remove libqemu target Makefile.objs: Remove libqemu_common.a from the comment LICENSE: There is no libqemu.a anymore LICENSE |4 +- Makefile.objs |7 +- Makefile.target |8 -- qemu-tech.texi | 10 -- tests/Makefile |6 - tests/qruncom.c | 284 --- 6 files changed, 4 insertions(+), 315 deletions(-) delete mode 100644 tests/qruncom.c -- 1.7.3.4
[Qemu-devel] [PATCH 2/6 v2] tests/Makefile: Remove qruncom target
From: Chen Wei-Ren che...@iis.sinica.edu.tw Remove qruncom target from the Makefile file since we have removed libqemu example (qruncom.c). Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw --- tests/Makefile |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/tests/Makefile b/tests/Makefile index 430e0c1..15e36a2 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -115,12 +115,6 @@ speed: sha1 sha1-i386 time ./sha1 time $(QEMU) ./sha1-i386 -# broken test -# NOTE: -fomit-frame-pointer is currently needed : this is a bug in libqemu -qruncom: qruncom.c ../ioport-user.c ../i386-user/libqemu.a - $(CC) $(CFLAGS) -fomit-frame-pointer $(LDFLAGS) -I../target-i386 -I.. -I../i386-user -I../fpu \ - -o $@ $(filter %.c, $^) -L../i386-user -lqemu -lm - # arm test hello-arm: hello-arm.o arm-linux-ld -o $@ $ -- 1.7.3.4
[Qemu-devel] [PATCH 3/6 v2] qemu-tech.texi: Remove libqemu related stuff from the document
From: Chen Wei-Ren che...@iis.sinica.edu.tw
Remove libqemu related stuff from the document since libqemu.a is not
supported
anymore.
v1 - v2: Remove entry qruncom.c from 3 Regression Tests.
Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw
---
qemu-tech.texi | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/qemu-tech.texi b/qemu-tech.texi
index 62afe45..5676fb7 100644
--- a/qemu-tech.texi
+++ b/qemu-tech.texi
@@ -96,10 +96,6 @@ Alpha and S390 hosts, but TCG (see below) doesn't support
those yet.
@item Precise exceptions support.
-@item The virtual CPU is a library (@code{libqemu}) which can be used
-in other projects (look at @file{qemu/tests/qruncom.c} to have an
-example of user mode @code{libqemu} usage).
-
@item
Floating point library supporting both full software emulation and
native host FPU instructions.
@@ -685,7 +681,6 @@ are available. They are used for regression testing.
@menu
* test-i386::
* linux-test::
-* qruncom.c::
@end menu
@node test-i386
@@ -711,11 +706,6 @@ This program tests various Linux system calls. It is used
to verify
that the system call parameters are correctly converted between target
and host CPUs.
-@node qruncom.c
-@section @file{qruncom.c}
-
-Example of usage of @code{libqemu} to emulate a user mode i386 CPU.
-
@node Index
@chapter Index
@printindex cp
--
1.7.3.4
Re: [Qemu-devel] [PATCH 2/6 v2] tests/Makefile: Remove qruncom target
On Fri, Nov 11, 2011 at 03:02:16PM +, Peter Maydell wrote: On 11 November 2011 14:53, Chen Wei-Ren (陳韋任) che...@iis.sinica.edu.tw wrote: From: Chen Wei-Ren che...@iis.sinica.edu.tw Remove qruncom target from the Makefile file since we have removed libqemu example (qruncom.c). This should be done before the patch removing qruncom.c, not after. Or do both in the same patch. I'll reverse the order next time. Is there a rule of thumb about how to order those patches? 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] [PATCH 4/6 v2] Makefile.target: Remove libqemu target
This commit isn't doing what the commit message claims it does. What you're actually removing is a set of manually inserted dependencies of some object files on their source files and on cpu.h. There is already no libqemu target in this makefile. What you maybe wanted to remove is just the now out of date comment line? I thought the lines below # libqemu is related to libqemu.a , but it's apparently not. Now, I think those manually inserted dependencies shouldn't be there, because the autogenerated .d files already cover the dependencies they specify as far as I can tell. You mean those *.d file under the build directory? But that would be a different commit entirely.) I'll exclude those manually inserted dependencies from this series 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] [ICON] QEMU Mascot Contest v.2
This is awesome! I'm worried how well it will scale down though. If you do the emu part on the right side, vertically, between the bottom of its head and top of its foot, you can shrink the Q part a bit to make the emu's body more proportional and leave more space for the emu text on the right. Not sure what you mean, but ... http://people.cs.nctu.edu.tw/~chenwj/slide/QEMU/QEMU_Mascot_v2.svg 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 question
2011/11/9 ad...@mmri.us ad...@mmri.us: qemu-users is dead. You subscribe and nothing happens. You mean http://tech.groups.yahoo.com/group/qemu-users/ is dead? Try https://lists.nongnu.org/mailman/listinfo/qemu-discuss , then. :-) 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] Accessing a linux guest's data structures
Thanks for the suggestions, guys! I will take a look at libvmi. As an aside, can someone tell me where in the qemu source can I inspect each guest instruction? I want all guest instructions to first go through my code. For i386 guest, see disas_insn (target-i386/translate.c). It disassembles i386 guest binary. QEMU provides -d in_asm option to log every guest instruction it translates. You might want to take a look on qemu_log. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] multiprocessor on kvm
I am wondering that when one uses qemu with kvm. How many cores are exposed and available to the guest os ( assuming the host has 4 cores ). is this configurable ? QEMU provides -smp option, but those virtual cpus are scheduled in round-robin fashion. In other words, it's not real parallelism. I don't know if there is any difference with kvm enabled. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] multiprocessor on kvm
On Tue, Nov 08, 2011 at 08:04:44PM +0800, 陳韋任 wrote: I am wondering that when one uses qemu with kvm. How many cores are exposed and available to the guest os ( assuming the host has 4 cores ). is this configurable ? QEMU provides -smp option, but those virtual cpus are scheduled in round-robin fashion. In other words, it's not real parallelism. I don't know if there is any difference with kvm enabled. IIRC, kvm uses QEMU for device emulation only. Those virtual cpus are ran on physical cpus simultaneously. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
[Qemu-devel] [PATCH 0/6] Remove libqemu related stuff from QEMU source tree
From: Chen Wei-Ren che...@iis.sinica.edu.tw According to [1], libqemu is not available anymore. Remove libqemu related stuff from QEMU source tree. [1] http://www.mail-archive.com/qemu-devel@nongnu.org/msg49809.html Chen Wen-Ren (6): tests/qruncom.c: Remove libqemu.a example tests/Makefile: Remove qruncom target qemu-tech.texi: Remove libqemu related stuff from the document Makefile.target: Remove libqemu target Makefile.objs: Remove libqemu_common.a target LICENSE: There is no libqemu.a anymore LICENSE |4 +- Makefile.objs | 104 Makefile.target |8 -- qemu-tech.texi |9 -- tests/Makefile |6 - tests/qruncom.c | 284 --- 6 files changed, 1 insertions(+), 414 deletions(-) delete mode 100644 tests/qruncom.c -- 1.7.3.4
[Qemu-devel] [PATCH 1/6] tests/qruncom.c: Remove libqemu.a example
From: Chen Wei-Ren che...@iis.sinica.edu.tw
Remove libqemu example since libqemu.a is not available anymore.
Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw
---
tests/qruncom.c | 284 ---
1 files changed, 0 insertions(+), 284 deletions(-)
delete mode 100644 tests/qruncom.c
diff --git a/tests/qruncom.c b/tests/qruncom.c
deleted file mode 100644
index 2e93aaf..000
--- a/tests/qruncom.c
+++ /dev/null
@@ -1,284 +0,0 @@
-/*
- * Example of use of user mode libqemu: launch a basic .com DOS
- * executable
- */
-#include stdlib.h
-#include stdio.h
-#include string.h
-#include inttypes.h
-#include unistd.h
-#include fcntl.h
-#include sys/mman.h
-#include signal.h
-#include malloc.h
-
-#include cpu.h
-
-//#define SIGTEST
-
-int cpu_get_pic_interrupt(CPUState *env)
-{
-return -1;
-}
-
-uint64_t cpu_get_tsc(CPUState *env)
-{
-return 0;
-}
-
-static void set_gate(void *ptr, unsigned int type, unsigned int dpl,
- unsigned long addr, unsigned int sel)
-{
-unsigned int e1, e2;
-e1 = (addr 0x) | (sel 16);
-e2 = (addr 0x) | 0x8000 | (dpl 13) | (type 8);
-stl((uint8_t *)ptr, e1);
-stl((uint8_t *)ptr + 4, e2);
-}
-
-uint64_t idt_table[256];
-
-/* only dpl matters as we do only user space emulation */
-static void set_idt(int n, unsigned int dpl)
-{
-set_gate(idt_table + n, 0, dpl, 0, 0);
-}
-
-void g_free(void *ptr)
-{
-free(ptr);
-}
-
-void *g_malloc(size_t size)
-{
-return malloc(size);
-}
-
-void *g_malloc0(size_t size)
-{
-void *ptr;
-ptr = g_malloc(size);
-if (!ptr)
-return NULL;
-memset(ptr, 0, size);
-return ptr;
-}
-
-void *qemu_vmalloc(size_t size)
-{
-return memalign(4096, size);
-}
-
-void qemu_vfree(void *ptr)
-{
-free(ptr);
-}
-
-void qemu_printf(const char *fmt, ...)
-{
-va_list ap;
-va_start(ap, fmt);
-vprintf(fmt, ap);
-va_end(ap);
-}
-
-/* XXX: this is a bug in helper2.c */
-int errno;
-
-/**/
-
-#define COM_BASE_ADDR0x10100
-
-static void usage(void)
-{
-printf(qruncom version 0.1 (c) 2003 Fabrice Bellard\n
- usage: qruncom file.com\n
- user mode libqemu demo: run simple .com DOS executables\n);
-exit(1);
-}
-
-static inline uint8_t *seg_to_linear(unsigned int seg, unsigned int reg)
-{
-return (uint8_t *)((seg 4) + (reg 0x));
-}
-
-static inline void pushw(CPUState *env, int val)
-{
-env-regs[R_ESP] = (env-regs[R_ESP] ~0x) | ((env-regs[R_ESP] - 2)
0x);
-*(uint16_t *)seg_to_linear(env-segs[R_SS].selector, env-regs[R_ESP]) =
val;
-}
-
-static void host_segv_handler(int host_signum, siginfo_t *info,
- void *puc)
-{
-if (cpu_signal_handler(host_signum, info, puc)) {
-return;
-}
-abort();
-}
-
-int main(int argc, char **argv)
-{
-uint8_t *vm86_mem;
-const char *filename;
-int fd, ret, seg;
-CPUState *env;
-
-if (argc != 2)
-usage();
-filename = argv[1];
-
-vm86_mem = mmap((void *)0x, 0x11,
-PROT_WRITE | PROT_READ | PROT_EXEC,
-MAP_FIXED | MAP_ANON | MAP_PRIVATE, -1, 0);
-if (vm86_mem == MAP_FAILED) {
-perror(mmap);
-exit(1);
-}
-
-/* load the MSDOS .com executable */
-fd = open(filename, O_RDONLY);
-if (fd 0) {
-perror(filename);
-exit(1);
-}
-ret = read(fd, vm86_mem + COM_BASE_ADDR, 65536 - 256);
-if (ret 0) {
-perror(read);
-exit(1);
-}
-close(fd);
-
-/* install exception handler for CPU emulator */
-{
-struct sigaction act;
-
-sigfillset(act.sa_mask);
-act.sa_flags = SA_SIGINFO;
-//act.sa_flags |= SA_ONSTACK;
-
-act.sa_sigaction = host_segv_handler;
-sigaction(SIGSEGV, act, NULL);
-sigaction(SIGBUS, act, NULL);
-}
-
-//cpu_set_log(CPU_LOG_TB_IN_ASM | CPU_LOG_TB_OUT_ASM | CPU_LOG_EXEC);
-
-env = cpu_init(qemu32);
-
-cpu_x86_set_cpl(env, 3);
-
-env-cr[0] = CR0_PG_MASK | CR0_WP_MASK | CR0_PE_MASK;
-/* NOTE: hflags duplicates some of the virtual CPU state */
-env-hflags |= HF_PE_MASK | VM_MASK;
-
-/* flags setup : we activate the IRQs by default as in user
- mode. We also activate the VM86 flag to run DOS code */
-env-eflags |= IF_MASK | VM_MASK;
-
-/* init basic registers */
-env-eip = 0x100;
-env-regs[R_ESP] = 0xfffe;
-seg = (COM_BASE_ADDR - 0x100) 4;
-
-cpu_x86_load_seg_cache(env, R_CS, seg,
- (seg 4), 0x, 0);
-cpu_x86_load_seg_cache(env, R_SS, seg,
- (seg 4), 0x, 0);
-cpu_x86_load_seg_cache(env, R_DS, seg,
- (seg 4), 0x, 0);
-cpu_x86_load_seg_cache(env, R_ES, seg,
- (seg 4), 0x, 0);
-cpu_x86_load_seg_cache(env,
[Qemu-devel] [PATCH 2/6] tests/Makefile: Remove qruncom target
From: Chen Wei-Ren che...@iis.sinica.edu.tw Remove qruncom target from the Makefile file since we have removed libqemu example (qruncom.c). Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw --- tests/Makefile |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/tests/Makefile b/tests/Makefile index 430e0c1..15e36a2 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -115,12 +115,6 @@ speed: sha1 sha1-i386 time ./sha1 time $(QEMU) ./sha1-i386 -# broken test -# NOTE: -fomit-frame-pointer is currently needed : this is a bug in libqemu -qruncom: qruncom.c ../ioport-user.c ../i386-user/libqemu.a - $(CC) $(CFLAGS) -fomit-frame-pointer $(LDFLAGS) -I../target-i386 -I.. -I../i386-user -I../fpu \ - -o $@ $(filter %.c, $^) -L../i386-user -lqemu -lm - # arm test hello-arm: hello-arm.o arm-linux-ld -o $@ $ -- 1.7.3.4
[Qemu-devel] [PATCH 3/6] qemu-tech.texi: Remove libqemu related stuff from the document
From: Chen Wei-Ren che...@iis.sinica.edu.tw
Remove libqemu related stuff from the document since libqemu.a is not
supported
anymore.
Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw
---
qemu-tech.texi |9 -
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/qemu-tech.texi b/qemu-tech.texi
index 397b070..f307eff 100644
--- a/qemu-tech.texi
+++ b/qemu-tech.texi
@@ -96,10 +96,6 @@ Alpha and S390 hosts, but TCG (see below) doesn't support
those yet.
@item Precise exceptions support.
-@item The virtual CPU is a library (@code{libqemu}) which can be used
-in other projects (look at @file{qemu/tests/qruncom.c} to have an
-example of user mode @code{libqemu} usage).
-
@item
Floating point library supporting both full software emulation and
native host FPU instructions.
@@ -711,11 +707,6 @@ This program tests various Linux system calls. It is used
to verify
that the system call parameters are correctly converted between target
and host CPUs.
-@node qruncom.c
-@section @file{qruncom.c}
-
-Example of usage of @code{libqemu} to emulate a user mode i386 CPU.
-
@node Index
@chapter Index
@printindex cp
--
1.7.3.4
[Qemu-devel] [PATCH 4/6] Makefile.target: Remove libqemu target
From: Chen Wei-Ren che...@iis.sinica.edu.tw Remove libqemu target from Makefile.target. Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw --- Makefile.target |8 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/Makefile.target b/Makefile.target index a111521..d1f7993 100644 --- a/Makefile.target +++ b/Makefile.target @@ -92,14 +92,6 @@ tci-dis.o: QEMU_CFLAGS += -I$(SRC_PATH)/tcg -I$(SRC_PATH)/tcg/tci $(libobj-y): $(GENERATED_HEADERS) -# libqemu - -translate.o: translate.c cpu.h - -translate-all.o: translate-all.c cpu.h - -tcg/tcg.o: cpu.h - # HELPER_CFLAGS is used for all the code compiled with static register # variables op_helper.o ldst_helper.o user-exec.o: QEMU_CFLAGS += $(HELPER_CFLAGS) -- 1.7.3.4
Re: [Qemu-devel] multiprocessor on kvm
so qemu exposes multiple processors to the guest os by having multiple vCPUs. and it realizes the multiple vCPUs by either using RR on a single host cpu (qemu ) or using multiple host cpus (kvm). yes. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
[Qemu-devel] [PATCH 5/6] Makefile.objs: Remove libqemu_common.a target
From: Chen Wen-Ren che...@iis.sinica.edu.tw Remove libqemu_common.a target from Makefile.objs. Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw --- Makefile.objs | 104 - 1 files changed, 0 insertions(+), 104 deletions(-) diff --git a/Makefile.objs b/Makefile.objs index d7a6539..ba8879c 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -68,110 +68,6 @@ endif fsdev-obj-$(CONFIG_VIRTFS) += $(addprefix fsdev/, $(fsdev-nested-y)) ## -# libqemu_common.a: Target independent part of system emulation. The -# long term path is to suppress *all* target specific code in case of -# system emulation, i.e. a single QEMU executable should support all -# CPUs and machines. - -common-obj-y = $(block-obj-y) blockdev.o -common-obj-y += $(net-obj-y) -common-obj-y += $(qobject-obj-y) -common-obj-$(CONFIG_LINUX) += $(fsdev-obj-$(CONFIG_LINUX)) -common-obj-y += readline.o console.o cursor.o -common-obj-y += $(oslib-obj-y) -common-obj-$(CONFIG_WIN32) += os-win32.o -common-obj-$(CONFIG_POSIX) += os-posix.o - -common-obj-y += tcg-runtime.o host-utils.o main-loop.o -common-obj-y += irq.o input.o -common-obj-$(CONFIG_PTIMER) += ptimer.o -common-obj-$(CONFIG_MAX7310) += max7310.o -common-obj-$(CONFIG_WM8750) += wm8750.o -common-obj-$(CONFIG_TWL92230) += twl92230.o -common-obj-$(CONFIG_TSC2005) += tsc2005.o -common-obj-$(CONFIG_LM832X) += lm832x.o -common-obj-$(CONFIG_TMP105) += tmp105.o -common-obj-$(CONFIG_STELLARIS_INPUT) += stellaris_input.o -common-obj-$(CONFIG_SSD0303) += ssd0303.o -common-obj-$(CONFIG_SSD0323) += ssd0323.o -common-obj-$(CONFIG_ADS7846) += ads7846.o -common-obj-$(CONFIG_MAX111X) += max111x.o -common-obj-$(CONFIG_DS1338) += ds1338.o -common-obj-y += i2c.o smbus.o smbus_eeprom.o -common-obj-y += eeprom93xx.o -common-obj-y += scsi-disk.o cdrom.o -common-obj-y += scsi-generic.o scsi-bus.o -common-obj-y += hid.o -common-obj-y += usb.o usb-hub.o usb-$(HOST_USB).o usb-hid.o usb-msd.o usb-wacom.o -common-obj-y += usb-serial.o usb-net.o usb-bus.o usb-desc.o -common-obj-$(CONFIG_SSI) += ssi.o -common-obj-$(CONFIG_SSI_SD) += ssi-sd.o -common-obj-$(CONFIG_SD) += sd.o -common-obj-y += bt.o bt-host.o bt-vhci.o bt-l2cap.o bt-sdp.o bt-hci.o bt-hid.o usb-bt.o -common-obj-y += bt-hci-csr.o -common-obj-y += buffered_file.o migration.o migration-tcp.o -common-obj-y += qemu-char.o savevm.o #aio.o -common-obj-y += msmouse.o ps2.o -common-obj-y += qdev.o qdev-properties.o -common-obj-y += block-migration.o iohandler.o -common-obj-y += pflib.o -common-obj-y += bitmap.o bitops.o - -common-obj-$(CONFIG_BRLAPI) += baum.o -common-obj-$(CONFIG_POSIX) += migration-exec.o migration-unix.o migration-fd.o -common-obj-$(CONFIG_WIN32) += version.o - -common-obj-$(CONFIG_SPICE) += ui/spice-core.o ui/spice-input.o ui/spice-display.o spice-qemu-char.o - -audio-obj-y = audio.o noaudio.o wavaudio.o mixeng.o -audio-obj-$(CONFIG_SDL) += sdlaudio.o -audio-obj-$(CONFIG_OSS) += ossaudio.o -audio-obj-$(CONFIG_SPICE) += spiceaudio.o -audio-obj-$(CONFIG_COREAUDIO) += coreaudio.o -audio-obj-$(CONFIG_ALSA) += alsaaudio.o -audio-obj-$(CONFIG_DSOUND) += dsoundaudio.o -audio-obj-$(CONFIG_FMOD) += fmodaudio.o -audio-obj-$(CONFIG_ESD) += esdaudio.o -audio-obj-$(CONFIG_PA) += paaudio.o -audio-obj-$(CONFIG_WINWAVE) += winwaveaudio.o -audio-obj-$(CONFIG_AUDIO_PT_INT) += audio_pt_int.o -audio-obj-$(CONFIG_AUDIO_WIN_INT) += audio_win_int.o -audio-obj-y += wavcapture.o -common-obj-y += $(addprefix audio/, $(audio-obj-y)) - -ui-obj-y += keymaps.o -ui-obj-$(CONFIG_SDL) += sdl.o sdl_zoom.o x_keymap.o -ui-obj-$(CONFIG_COCOA) += cocoa.o -ui-obj-$(CONFIG_CURSES) += curses.o -vnc-obj-y += vnc.o d3des.o -vnc-obj-y += vnc-enc-zlib.o vnc-enc-hextile.o -vnc-obj-y += vnc-enc-tight.o vnc-palette.o -vnc-obj-y += vnc-enc-zrle.o -vnc-obj-$(CONFIG_VNC_TLS) += vnc-tls.o vnc-auth-vencrypt.o -vnc-obj-$(CONFIG_VNC_SASL) += vnc-auth-sasl.o -ifdef CONFIG_VNC_THREAD -vnc-obj-y += vnc-jobs-async.o -else -vnc-obj-y += vnc-jobs-sync.o -endif -common-obj-y += $(addprefix ui/, $(ui-obj-y)) -common-obj-$(CONFIG_VNC) += $(addprefix ui/, $(vnc-obj-y)) - -common-obj-y += iov.o acl.o -common-obj-$(CONFIG_POSIX) += compatfd.o -common-obj-y += notify.o event_notifier.o -common-obj-y += qemu-timer.o qemu-timer-common.o - -slirp-obj-y = cksum.o if.o ip_icmp.o ip_input.o ip_output.o -slirp-obj-y += slirp.o mbuf.o misc.o sbuf.o socket.o tcp_input.o tcp_output.o -slirp-obj-y += tcp_subr.o tcp_timer.o udp.o bootp.o tftp.o arp_table.o -common-obj-$(CONFIG_SLIRP) += $(addprefix slirp/, $(slirp-obj-y)) - -# xen backend driver support -common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o -common-obj-$(CONFIG_XEN_BACKEND) += xen_console.o xenfb.o xen_disk.o xen_nic.o - -## # libuser user-obj-y = -- 1.7.3.4
[Qemu-devel] [PATCH 6/6] LICENSE: There is no libqemu.a anymore
From: Chen Wei-Ren che...@iis.sinica.edu.tw Remove statement about libqemu.a from LICENSE. Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw --- LICENSE |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/LICENSE b/LICENSE index cbd92c0..acae9a3 100644 --- a/LICENSE +++ b/LICENSE @@ -6,9 +6,7 @@ The following points clarify the QEMU license: GNU General Public License. Hence each source file contains its own licensing information. -In particular, the QEMU virtual CPU core library (libqemu.a) is -released under the GNU Lesser General Public License. Many hardware -device emulation sources are released under the BSD license. +Many hardware device emulation sources are released under the BSD license. 3) The Tiny Code Generator (TCG) is released under the BSD license (see license headers in files). -- 1.7.3.4
Re: [Qemu-devel] [Qemu-trivial] [PATCH v2] ui/vnc: Convert sasl.mechlist to g_malloc() friends
Stefan Hajnoczi stefa...@gmail.com writes: On Tue, Nov 8, 2011 at 12:45 PM, Markus Armbruster arm...@redhat.com wrote: Fixes protocol_client_auth_sasl_mechname() not to crash when malloc() fails. Spotted by Coverity. --- ui/vnc-auth-sasl.c | 19 +-- 1 files changed, 5 insertions(+), 14 deletions(-) Looks good, please add Signed-off-by. Gaa, too trivial to get it right in less than three tries! There must a curse of brainlessness on this one... `git-format-patch -s` will generate the sign-off-by. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] [PATCH 0/6] Remove libqemu related stuff from QEMU source tree
Please thread together your patches so that the parts appear as replies to the cover letter. git-send-email should do that by default. Why? Disconnected parts can easily get separated in the list. When that happens, your reviewers need to hunt for parts. They may choose to review something else instead. Can't blame them; reviewing is more productive than hunting for parts. Sorry about that. Should I re-sent this series? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] [PATCH 0/6] Remove libqemu related stuff from QEMU source tree
On Tue, Nov 08, 2011 at 04:07:12PM +0100, Markus Armbruster wrote: 陳韋任 che...@iis.sinica.edu.tw writes: Please thread together your patches so that the parts appear as replies to the cover letter. git-send-email should do that by default. Why? Disconnected parts can easily get separated in the list. When that happens, your reviewers need to hunt for parts. They may choose to review something else instead. Can't blame them; reviewing is more productive than hunting for parts. Sorry about that. Should I re-sent this series? Try that if you don't get reviews ;) Else just get it right with your next patch series. O.K.. Just want to make sure. What you said thread together your patches has something to do with sendemail.chainreplyto? I found I sent this series one by one, i.e., `git send-email 000#.patch`. I think I should sent them as a whole, i.e., `git send-email *`. But I am not sure sendemail.chainreplyto matters or not. 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
Re: [Qemu-devel] [PATCH 0/6] Remove libqemu related stuff from QEMU source tree
If you enable sendemail.chainreplyto then each letter in a series (except the first) will go as a reply to the previous letter. If you omit sendemail.chainreplyto then letters following the first one will go as replies to that first letter. Second option is commonly used and IMHO a bit easier to read than the first. I set chainreplyto = false in my .gitconfig, then. :) Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] [PATCH 0/6] Remove libqemu related stuff from QEMU source tree
Thanks, Markus and Peter. Max already explaind chainreplyto. I agree with him that chainreplyto off is preferable. But what you're after is --thread / sendemail.thread. See man git-send-email for details. The default is --thread, which does the threading, provided you send all parts at once. ^^^ I'll sent the series at once 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
Re: [Qemu-devel] [PATCH 5/6] Makefile.objs: Remove libqemu_common.a target
Have you build this? without this files qemu is not going to work. Perhaps the naming is wrong, and we should change common-obj to something else, but it is still needed to get things working as expected. Sorry, I have only tested i386-linux-user when I sent the patch. And i386-softmmu cannot be compiled. My mistake. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] [PATCH 5/6] Makefile.objs: Remove libqemu_common.a target
Have you build this? without this files qemu is not going to work. Perhaps the naming is wrong, and we should change common-obj to something else, but it is still needed to get things working as expected. I found the line below in Makefile, $(filter %-softmmu,$(SUBDIR_RULES)): $(trace-obj-y) $(common-obj-y) subdir-libdis I guess you ran into trouble while building *-softmmu? I think we can just remove libqemu_common.a: from the comment of common-obj-y and leave the rest part alone. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] [PATCH 5/6] Makefile.objs: Remove libqemu_common.a target
$(filter %-softmmu,$(SUBDIR_RULES)): $(trace-obj-y) $(common-obj-y) subdir-libdis I guess you ran into trouble while building *-softmmu? I think we can just remove libqemu_common.a: from the comment of common-obj-y and leave the rest part alone. Yes, please. I believe I'm the one to blame, I replaced the .a target with these lists of .o files to fix the build on OpenSolaris after constructors was introduced. So you agree to remove libqemu_common.a: from the comment or? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] multiprocessor on kvm
I am wondering when using -smp 16 and --enable-kvm at the same time (while the host has 4 cores), what will happen? -smp 16 will lauch 16 virtual cpu threads, and --enable-kvm means you run those threads on physical cpus *at the same time*. How 16 virtual cpu threads are scheduled on 4 physical cpus is done by host OS. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] qemu question
I apologize for asking this question on the developers group, but the users group is dead. https://lists.nongnu.org/mailman/listinfo/qemu-discuss http://tech.groups.yahoo.com/group/qemu-users/ Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] Patch: fix typo: runnning - running
Better cc to qemu-triv...@nongnu.org
On Mon, Nov 07, 2011 at 03:58:23PM -0800, Vagrant Cascadian wrote:
One n too many for running, need we say more.
Signed-Off-By: Vagrant Cascadian vagr...@freegeek.org
Index: qemu/target-i386/kvm.c
===
--- qemu.orig/target-i386/kvm.c 2011-07-02 21:25:10.0 -0700
+++ qemu/target-i386/kvm.c2011-07-02 21:25:20.0 -0700
@@ -1537,7 +1537,7 @@
code);
if (host_supports_vmx() code == VMX_INVALID_GUEST_STATE) {
fprintf(stderr,
-\nIf you're runnning a guest on an Intel machine
without
+\nIf you're running a guest on an Intel machine without
unrestricted mode\n
support, the failure can be most likely due to the
guest
entering an invalid\n
live well,
vagrant
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] How to build QEMU from git
I ran into a problem running the qemu-0.15 and I was told that the problem was fixed in the 1.0 release candidate. I don't find a package with the RC on http://wiki.qemu.org/Download, There is a qemu-1.0-rc1 on the page now. :) Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] Accessing a linux guest's data structures
Hi I am a beginner qemu developer. I am running a linux guest inside qemu and I need to determine what process, thread is currently running in the guest. How should I do this? Any suggestions? Or can anyone point me to the relevant areas in qemu's source. ^^^ I guess he want to know how to know which process is running in the guest OS from QEMU's perspective. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
[Qemu-devel] How QEMU handle self-modifying code?
Hi, all While studying how QEMU handle self-modifying code I took [1] as an example. Running QEMU under GDB I found tb_invalidate_phys_page is called in two different call sequences: 1. do_syscall (linux-user/syscall.c) - target_mprotect (linux-user/mmap.c) - page_set_flags (exec.c) - tb_invalidate_phys_page (exec.c) 2. host_signal_handler (linux-user/signal.c) - cpu_x86_signal_handler (user-exec.c) - handle_cpu_signal (user-exec.c) - page_unprotect (exec.c) - tb_invalidate_phys_page (exec.c) Both eventually call tb_invalidate_phys_page. If a guest page is being modified, I think tb_invalidate_phys_page that page once is sufficient. But it's apparently not in practice. After doing some comparisons bwteen those two call sequences (see below), I can only guess this has something to do with TARGET_HAS_PRECISE_SMC. --- 1st call sequence --- #0 tb_invalidate_phys_page (addr=134512640, pc=0, puc=0x0) #1 page_set_flags (start=134512640, end=134516736, flags=31) --- --- 2nd call sequence --- #0 tb_invalidate_phys_page (addr=134512640, pc=1612947916, puc=0x7fffd080) #1 page_unprotect (address=134514145, pc=1612947916, puc=0x7fffd080) --- But what TARGET_HAS_PRECISE_SMC is? *If* we don't have to support TARGET_HAS_PRECISE_SMC, does it imply there is no need to call tb_invalidate_phys_page twice? Thanks! [1] http://web.archive.org/web/20080618094733/http://public.carnet.hr/~jbrecak/sm.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
Re: [Qemu-devel] Why some ARM NEON helper functions need mask?
Thanks, Max and Chih-Min. It's much clear to me now. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
[Qemu-devel] Why some ARM NEON helper functions need mask?
Hi, all
I am looking into QEMU's implementation for ARM NEON instructions
(target-arm/neon_helper.c). Some helper functions will do mask
operation, neon_add_u8, for example. I thought simply adding a and b
is enough and can't figure out why the mask operation is needed.
---
uint32_t HELPER(neon_add_u8)(uint32_t a, uint32_t b)
{
uint32_t mask;
mask = (a ^ b) 0x80808080u;
a = ~0x80808080u;
b = ~0x80808080u;
return (a + b) ^ mask;
}
---
Any help is appreciated.
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] Multi heterogenous CPU archs for SoC sim?
My use case here is testing and debugging, so I think we could live with the blocks being executed in an interleaved fashion until someone has the ultimate parallelization solution for upstream. So you prefer parallelizing QEMU itself in your case? -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
