Re: [Qemu-devel] qemu cpu-all.h exec.c

[Fabrice Bellard <fabrice@bellard.org>]

Blue Swirl wrote:
> On 1/3/08, Paul Brook <paul@codesourcery.com> wrote:
>> On Wednesday 02 January 2008, Blue Swirl wrote:
>>> On 1/2/08, Paul Brook <paul@codesourcery.com> wrote:
>>>>> Also the opaque parameter may need to be different for each function,
>>>>> it just didn't matter for the unassigned memory case.
>>>> Do you really have systems where independent devices need to respond to
>>>> different sized accesses to the same address?
>>> I don't think so. But one day unassigned or even normal RAM memory
>>> access may need an opaque parameter, so passing the device's opaque to
>>> unassigned memory handler is wrong.
>> I'm not convinced.  Your current implementation seems to introduce an extra
>> level of indirection without any plausible benefit.
>>
>> If you're treating unassigned memory differently it needs to be handled much
>> earlier that so you can raise CPU exceptions.
> 
> Earlier, where's that?
> 
> Another approach could be conditional stacked handlers, where a higher
> level handler could pass the access request to lower one (possibly
> modifying it in flight) or handle completely. Maybe this solves the
> longstanding generic DMA issue if taken to the device to memory
> direction.

As I said earlier, the only correct way to handle memory accesses is to 
be able to consider a memory range and its associated I/O callbacks as 
an object which can be installed _and_ removed. It implies that there is 
a priority system close to what you described. It is essential to 
correct long standing PCI bugs for example.

Regards,

Fabrice.