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

[J. Mayer]

On Mon, 2007-10-15 at 23:42 +0100, Paul Brook wrote:
> > > 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.

Well, we got the same behavior on PowerPC. What I was thinking of is
that if we fix the VLE problems, the fix, if done in a proper way, could
also allow benefit to RISC targets. What I don't know is; would we
really have a benefit not stopping translation on page boundaries ?

> 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.

I think that it would be possible to do things properly. I'm not really
sure what is the best solution to implement it but if, in the "slow
case" path of the code fetch low-level routine, we call the
get_physical_address or the cpu_get_phys_page_debug function, we then
have a way to know if the code fetch is allowed. If it, we would just
have to adjust our host_pc and host_pc_start for the next fetch to be
optimized. If not, we could stop the translation and generate a
"gen_op_raise_excp_error" to raise the exception at the right place,
respecting the ISA insns execution ordering. Generating the exception
from inside the TB won't be OK, as it may not be necessary on a second
execution of the same TB, then the solution may be to link the TB with a
special other TB that would just raise this exception and would be
unlink once the exception has been treated. Or maybe the solution would
just be to stop the translation knowing that the exception will be
raised when trying to translate the first instruction in the next page.
There still may be specific problems for instructions spanning 2 pages,
using those solutions...

-- 
J. Mayer <address@hidden>
Never organized