From: Jan Kiszka <jan.kiszka@web.de>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [RFC][PATCH] x86: CS limit checks
Date: Thu, 17 Jul 2008 23:30:48 +0200 [thread overview]
Message-ID: <487FBA08.3010105@web.de> (raw)
In-Reply-To: <487F9C7C.3070304@bellard.org>
[-- Attachment #1: Type: text/plain, Size: 1441 bytes --]
Fabrice Bellard wrote:
> Paul Brook wrote:
>>> To me it looks like as if the generator can so far raise a PF
>>> prematurely when it steps on an invalid code address while building a
>>> new TB. This probably has to fix the same way as the limit check is
>>> realized: by injecting an exception (PF or GP) into the generated code
>>> at the correct PC. Hmm, the PF-during-translation issue is probably not
>>> just limited to x86...
>>
>> Alpha, PPC, SPARC, SH and ARM avoid the problem by having fixed length
>> word aligned instructions. Thumb-1 has special handling for the
>> cross-boundary case (Instructions aren't really variable length, we
>> just treat them that way as an optimisation).
>>
>> Thumb-2, m68k, cris and x86 all look like they may incorrectly fetch
>> code from the next page.
>
> For x86 it is an expected behavior, not a bug. However, I agree that it
> would be safer to explicitely generate the exception. My plan has always
> been to suppress the ldx_code functions and to explicitly handle the PF
> and the cs_limit cases.
This path offers another nice possibility: the introduction of a
separate code TLB. I bet this will improve the hit rate on both the
existing (and then data-only) TLB as well as the new one only for code.
> Jocelyn Mayer submitted some time ago a patch to
> go in that direction.
Any links or keywords at hand? So far I failed to find this patch.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
next prev parent reply other threads:[~2008-07-17 21:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-17 11:57 [Qemu-devel] [RFC][PATCH] x86: CS limit checks Jan Kiszka
2008-07-17 12:17 ` Paul Brook
2008-07-17 13:14 ` Jan Kiszka
2008-07-17 13:37 ` Paul Brook
2008-07-17 16:10 ` Jan Kiszka
2008-07-17 17:45 ` Paul Brook
2008-07-17 19:24 ` Fabrice Bellard
2008-07-17 21:30 ` Jan Kiszka [this message]
2008-07-17 14:06 ` Fabrice Bellard
2008-07-17 16:30 ` [Qemu-devel] " Jan Kiszka
2008-07-17 19:29 ` Fabrice Bellard
2008-07-17 21:25 ` Jan Kiszka
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=487FBA08.3010105@web.de \
--to=jan.kiszka@web.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.