On 10/25/2012 03:28 PM, Peter Maydell wrote: > On 25 October 2012 14:21, Avi Kivity <[email protected]> wrote: >> On 10/25/2012 03:12 PM, Peter Maydell wrote: >>> (2) what should the memory system do for accesses where there is >>> no memory region? This is really system specific as it depends >>> what the bus fabric does. For ARM the usual thing would be to >>> generate a decode error response which will result in the guest >>> CPU taking a data abort or prefetch abort. I don't think our >>> memory system currently has any way of saying "for this access >>> generate an exception"... >>> >> >> 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. If some other region decodes, the container region will be ignored, if nothing decodes, you get your exception. 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). We may also do something like MemoryRegionPortio, but not hacky, that lets you have a MemoryRegion for each register. That means that instead of writing two large functions that duplicates the decode, you write one function per register, and switch on transfer direction. -- error compiling committee.c: too many arguments to function
