On 25 October 2012 14:41, Avi Kivity <[email protected]> wrote: > On 10/25/2012 03:28 PM, Peter Maydell wrote: >> On 25 October 2012 14:21, Avi Kivity <[email protected]> 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
