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

[Peter Crosthwaite]

On Thu, Oct 25, 2012 at 11:50 PM, Peter Maydell
<address@hidden> wrote:
> 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.

If we want these features shouldnt we just bite the bullet and
impelement AXI with its own set of QOM definitions? Axi slaves then
inherit from TYPE_AXI_SLAVE. If we want ARM specific features then we
should replace SYSBUS with an ARM bus that does these things rather
than push them up to the memory API.

Add to that ARM bus feature list exclusive/non-exclusive as well.

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
>