[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [RFC][PATCH] x86: CS limit checks

From: Jan Kiszka
Subject: [Qemu-devel] Re: [RFC][PATCH] x86: CS limit checks
Date: Thu, 17 Jul 2008 23:30:48 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

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.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]