Re: [Qemu-devel] [5849] Change MMIO callbacks to use offsets, not absolute addresses.

[Blue Swirl]

On 2/24/09, Paul Brook <address@hidden> wrote:
> On Tuesday 24 February 2009, Robert Reif wrote:
>  > Paul Brook wrote:
>  > >> How do you propose having the hardware drivers generate meaningful and
>  > >> timely faults when an improper access is performed so it behaves like
>  > >> real low level software expects the hardware to behave?
>  > >
>  > > If you're wanting to generate faults from IO devices then getting the
>  > > right physical address is the least of your concerns. First you need to
>  > > figure out how to avoid corrupting the rest of the CPU state.
>  >
>
> > The MMU does it so it must be possible.  Is it a design issue, performance
>  > issue, just not worth the trouble or no one has really cared up until now?
>  > Please enlighten me further.  Is it reasonable to expect it to work someday
>  > or should I just accept that it won't?
>
>
> Bits of both. The TLB is tightly tied into the code generator. Once we get out
>  of the first-level TLB lookup you've not got anywhere near enough information
>  to be able to restore the CPU state. The only way to raise exceptions from
>  within an IO handler is to sync CPU state before every memory access, and you
>  really don't want to do that. This is why the existing unassigned access
>  fault code is busted.

But because of possible MMU and unaligned access faults we already
save PC and NPC (not in all cases). Handling of those faults works,
it's really needed for correct operation. For some faults PC/NPC save
is not necessary, the fault handler can calculate env->pc from host
PC. Why would the unassigned fault be different?