From: Rob Landley <rob@landley.net>
To: Max Filippov <jcmvbkbc@gmail.com>
Cc: qemu-devel@nongnu.org, 陳韋任 <chenwj@iis.sinica.edu.tw>
Subject: Re: [Qemu-devel] The reason behind block linking constraint?
Date: Sat, 20 Aug 2011 15:54:10 -0500 [thread overview]
Message-ID: <4E501EF2.6050406@landley.net> (raw)
In-Reply-To: <CAMo8BfLgV6-FPvcUPsyZLswcE2sjHGoLL6QrepvV9sGv3fvLPA@mail.gmail.com>
On 08/18/2011 04:31 AM, Max Filippov wrote:
>> Hi, all
>>
>> I am trying to figure out why QEMU put some constraints on block
>> linking (chaining). Take x86 as an example, there are two places
>> put constraints on block linking, gen_goto_tb and cpu_exec.
>>
>> ----------------- gen_goto_tb (target-i386/translate.c) ---------------
>> /* NOTE: we handle the case where the TB spans two pages here */
>> if ((pc & TARGET_PAGE_MASK) == (tb->pc & TARGET_PAGE_MASK) ||
>> (pc & TARGET_PAGE_MASK) == ((s->pc - 1) & TARGET_PAGE_MASK)) {
>> /* jump to same page: we can use a direct jump */
>> tcg_gen_goto_tb(tb_num);
>> gen_jmp_im(eip);
>> tcg_gen_exit_tb((tcg_target_long)tb + tb_num);
>> } else {
>> /* jump to another page: currently not optimized */
>> gen_jmp_im(eip);
>> gen_eob(s);
>> }
>> -----------------------------------------------------------------------
>>
>> ----------------------- cpu_exec (cpu-exec.c) -------------------------
>> /* see if we can patch the calling TB. When the TB
>> spans two pages, we cannot safely do a direct
>> jump. */
>> if (next_tb != 0 && tb->page_addr[1] == -1) {
>> tb_add_jump((TranslationBlock *)(next_tb & ~3), next_tb & 3, tb);
>> }
>> -----------------------------------------------------------------------
>>
>> Is it just because we cannot optimize block linking which crosses page
>> boundary, or there are some correctness/safety issues should be considered?
>
> If we link a TB with another TB from the different page, then the
> second TB may disappear when the memory mapping changes and the
> subsequent direct jump from the first TB will crash qemu.
>
> I guess that this usually does not happen in usermode, because the
> guest would not modify executable code memory mapping. However I
> suppose that this is also possible.
Dynamic linking modifies guest code, requiring the page to be
retranslated. With lazy binding this can happen at any time, and
without PIE executables this can happen to just about any executable page.
Rob
next prev parent reply other threads:[~2011-08-20 20:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-18 6:33 [Qemu-devel] The reason behind block linking constraint? 陳韋任
2011-08-18 9:31 ` Max Filippov
2011-08-18 9:39 ` 陳韋任
2011-08-18 10:04 ` Max Filippov
2011-09-24 7:00 ` 陳韋任
2011-09-25 21:47 ` Max Filippov
2011-09-26 10:49 ` 陳韋任
2011-09-26 11:41 ` Max Filippov
2011-09-27 2:40 ` 陳韋任
2011-08-20 20:54 ` Rob Landley [this message]
2011-09-27 3:13 ` 陳韋任
2011-09-27 13:27 ` Rob Landley
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=4E501EF2.6050406@landley.net \
--to=rob@landley.net \
--cc=chenwj@iis.sinica.edu.tw \
--cc=jcmvbkbc@gmail.com \
--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).