Re: [Qemu-devel] [PATCH v1 8/8] usb/ehci: Put RAM in undefined MMIO regions

[Peter Maydell]

On 25 October 2012 14:41, Avi Kivity <address@hidden> wrote:
> On 10/25/2012 03:28 PM, Peter Maydell wrote:
>> On 25 October 2012 14:21, Avi Kivity <address@hidden> wrote:
>>> You could easily have the top-level container have ->ops that generate
>>> an exception.
>>
>> Ah, yes, there's an 'accepts' callback. (That's kind of awkward
>> as an API because it means your decode logic gets spread between
>> read, write and accept: there are some devices where it would be
>> nice to have the 'default:' case of the address switch say "unknown
>> offset, raise decode error". If the read callback took a uint64_t*
>> rather than returning the read data, we could make both read and
>> write return a success/decode-error type of status result.)
>
> I actually forgot about ->accepts().  But it isn't needed for this use
> case, just have the lowest priority region (the container) implement
> ->read/write that generate the exception

I don't understand this -- read/write don't have any way of saying
"please generate an exception". The only thing I can see in the
API that does that is returning false from accepts().

> wrt decode duplication, I've been thinking of a single ->service()
> callback that accepts a Transaction argument, including all the details
> (offset, data, and direction).

If we do this we should make sure that the Transaction allows us to
include CPU-architecture dependent info -- for ARM we would want to
model transaction attributes like 'secure/nonsecure', 'privileged/nonpriv',
'instruction/data', etc. You also want to include in the transaction
attributes who the master end of this transaction is (so a slave
can distinguish accesses from a particular CPU core in a cluster,
for instance). This would allow us to remove some of the current
nasty hacks where devices reach into the CPUArchState to  retrieve
info that should ideally be modelled as part of the bus transaction.

-- PMM