qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: 陳韋任 <chenwj@iis.sinica.edu.tw>
Cc: Max Filippov <jcmvbkbc@gmail.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] The reason behind block linking constraint?
Date: Tue, 27 Sep 2011 08:27:39 -0500	[thread overview]
Message-ID: <4E81CF4B.9040207@landley.net> (raw)
In-Reply-To: <20110927031353.GA72316@cs.nctu.edu.tw>

On 09/26/2011 10:13 PM, 陳韋任 wrote:
> Hi, Rob
> 
>>>>  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.
> 
>   Max and I have some discussion about the page boundary constraint
> of block linking. Maybe it's not worth to track cross-page block
> linking, for latter possible block unchaining. So there is a page
> boundary constraint.
> 
>   You said dynamic linking requires the page to be retranslated.
> Does that imply if there is NO page boundary constraint, user
> mode might crash? If so, does it occur frequently? Maybe small program
> just works fine without such constraint, I have to run something
> big to make QEMU crash?

The constraints you're talking about are on the translated code, dynamic
linking happens on the target code.  Changes to the target code require
regenerating the translated code, which happens with page granularity.

Rob

      reply	other threads:[~2011-09-27 13:27 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
2011-09-27  3:13     ` 陳韋任
2011-09-27 13:27       ` Rob Landley [this message]

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=4E81CF4B.9040207@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).