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

[Paul Brook <paul@codesourcery.com>]

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.

In practice you probably want to have the IO handler set a flag somewhere 
indicating that the access faulted, then add a check to the low-level TLB 
code to fault in much the same way as for a TLB fault. You can probably avoid 
slowing down the fast-path ram access case, but you're likely to take a hit 
on all IO operations.  Either way the fault mechanism is largely separate 
from the device. I'm pretty sure this is consistent with read hardware where 
the device just indicates that something bad happened, and the CPU figures 
out everything else itself.

Paul