On 11/09/2011 07:43 PM, Anthony Liguori wrote: >> Every MemoryRegion field in qemu today is either immutable or slaved to >> another register. We could have a system to annotate every field, but >> it's pointless. > > > If I'm writing a device and doing save/restore and I happen to use a > MemoryRegion, how do I determine that every field is either immutable > or slaved?
In general 'return true' should work. I have a hard time imagining a device where this doesn't hold. If all memory API functions are called with parameters that are functions of the state and only the state, you're good. >> The memory/mutators branch simplifies it by eliminating pseudo state >> like flash_mapped. > > > They just moved the derived state into the MemoryRegion, no? > They do not. We had this state in three places. memory/mutators folds ->flash_mapped and the MemoryRegion equivalent; they both still mirror the real device register. If we had an Observable interface for Registers, then we could make any write to the Register automatically update the MemoryRegion; as it is, we have to call device_update_mapping() after every write. >> Yes, ISR fields often have it (like virtio). > > Yes, but virtio-pci was a very special case to avoid taking an extra > exit. > > Do you know of any other than virtio-pci? All the ones I can think of > (RTC, Serial, etc.) are cleared with a write. Can't think of any offhand, but see http://verificationguild.com/modules.php?name=Forums&file=viewtopic&p=5724. Anyway, if something turns out not to be useful, we don't have to keep it in the core. >> This style of code really wants lambdas. Without them, we have 4-5 >> lines of boilerplate for each callback. Even then, it's worthwhile IMO >> (and many callbacks can be avoided, both read and write, or merged into >> a device_update_mapping or device_update_irq read-all-state style >> functions). > > > Yeah, I looked at this but wasn't happy with the results. In > practice, many devices end up implementing non-trivial logic when > register values change. > > What I was really interested in was coming up with a way to get really > high quality tracing of device register accesses. A Register can still dispatch to a common dispatch function. Another thing I'm thinking of is wrapping addr/size/value in a Transaction object, to keep the signatures trim. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.