Re: [Qemu-devel] RFC: Code fetch optimisation

[Paul Brook <paul@codesourcery.com>]

> > VLE targets (x86, m68k) can translate almost a full page of instructions,
> > and a page boundary can be anywhere within that block. Once we've spanned
> > multiple pages there's not point stopping translation immediately. We may
> > as well translate as many instructions as we can on the second page.
> >
> > I'd guess most TB are much smaller than a page, so on average only a few
> > instructions are going to come after the page boundary.
>
> This leads me to another reflexion. For fixed length encoding targets,
> we always stop translation when reaching a page boundary. If we keep
> using the current model and we optimize the slow case, it would be
> possible to stop only if we cross 2 pages boundary during code
> translation, and it seems that this case is not likely to happen. If we
> keep the current behavior, we could remove the second page_addr element
> in the tb structure and maybe optimize parts of the tb management and
> invalidation code.

The latter may be the only feasible option.

Some targets (ARMv5, maybe others) do not have an explicit fault address for 
MMU instruction faults. The faulting address is the address of the current 
instruction when the fault occurs. Prefetch aborts are generated at 
translation time, which effectively means the faulting instruction must be at 
the start of a TB. Terminating the TB on a page boundary guarantees this 
behavior.

For VLE targets we already get this wrong (the prefetch abort occurs some time 
before the faulting instruction executes). I don't know if this behavior is 
permitted by the ISA, but it's definitely possible to construct cases where 
it has visible effect.

Paul