On 10/25/2012 03:50 PM, Peter Maydell wrote: > 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().
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
