From: 陳韋任 <chenwj@iis.sinica.edu.tw>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] The reason behind block linking constraint? (Cont.)
Date: Thu, 15 Dec 2011 14:57:22 +0800 [thread overview]
Message-ID: <20111215065722.GA98733@cs.nctu.edu.tw> (raw)
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
next reply other threads:[~2011-12-15 6:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-15 6:57 陳韋任 [this message]
2011-12-15 7:53 ` [Qemu-devel] The reason behind block linking constraint? (Cont.) Zhi Yong Wu
2011-12-15 8:01 ` 陳韋任
2011-12-15 8:14 ` Zhi Yong Wu
2011-12-16 3:51 ` 陳韋任
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111215065722.GA98733@cs.nctu.edu.tw \
--to=chenwj@iis.sinica.edu.tw \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).