[Qemu-devel] The reason behind block linking constraint? (Cont.)

[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] The reason behind block linking constraint? (Cont.)

[Zhi Yong Wu]

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?

On Thu, Dec 15, 2011 at 2:57 PM, 陳韋任 <chenwj@iis.sinica.edu.tw> wrote:
> 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
>



-- 
Regards,

Zhi Yong Wu

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] The reason behind block linking constraint? (Cont.)

[Zhi Yong Wu]

On Thu, Dec 15, 2011 at 4:01 PM, 陳韋任 <chenwj@iis.sinica.edu.tw> wrote:
> 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?
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?

>
> 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



-- 
Regards,

Zhi Yong Wu

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