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

[Avi Kivity <avi@redhat.com>]

On 10/25/2012 03:50 PM, Peter Maydell wrote:
> On 25 October 2012 14:41, Avi Kivity <avi@redhat.com> wrote:
>> On 10/25/2012 03:28 PM, Peter Maydell wrote:
>>> On 25 October 2012 14:21, Avi Kivity <avi@redhat.com> 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().

read/write can call anything.  So if the SoC code installs the lowest
region, it has access to whatever mechanisms generate the exceptions.

(it may not have access to CPUState though).

> 
>> 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.

Sounds like good arguments for another sweep.



-- 
error compiling committee.c: too many arguments to function