Re: [Qemu-devel] [PATCH 4/5] integratorcp: convert integratorcm to VMState

[Avi Kivity <avi@redhat.com>]

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.