Re: [Qemu-devel] [PATCH] 64 bit I/O support v7

[Paul Brook <paul@codesourcery.com>]

> The right way to do this is to convert the whole tree at once
> so we don't need the helper functions and two versions of
> cpu_register_io_memory.
> 95% of the hardware drivers could be trivially converted and
> work fine.  

I think you're missing my point. It's the 95% of drivers that I don't want to 
have to "convert". I'm working on the assumption that devices that actually 
implement 64-bit transfers are the exception rather than the rule.

So we have three options:

1) Omit the 64-bit handler for most devices. This will trigger the subwith 
code and associated overhead for no good reason[1].
2) Implement a 64-bit handler for every single device. 90% of these are going 
to be identical trivial wrappers round the 32-bit function. Maybe 5% actually 
need 64-bit accesses, and 5% are broken because someone messed up a 
copy/paste.
3) Implement splitting of 64-bit accesses in generic code.  Devices that 
actually care about 64-bit accesses can install a handler. Everything else 
indicates that it wants accesses split, either by a magic handler or a 
different registration function.

Your current patch implements a broken version of (3), with a vague hope that 
we'll switch to (2) at some time in the future.

I'm suggesting we implement (3) properly from the start.

Paul

[1] I still don't understand why the subwidth code exists, It's seems rather 
unlikely we'll have two different devices responding to different types of 
access the same address range. That's a separate argument though.