On Tue, 30 Jul 2019 at 06:45, Rashmica Gupta <rashmic...@gmail.com> wrote: > > There are a couple of things I'm not confident about here: > - what should be in init vs realize?
We are not very good at documenting this distinction (and there's some bits of it I'm not sure about either), but: * init cannot contain anything that might fail * init cannot contain anything that affects the simulation * init shouldn't do anything that needs explicit cleanup (eg memory allocation) * property creation has to happen in init, because properties are set after init but before realize Thomas did a good blog post on this: http://people.redhat.com/~thuth/blog/qemu/2018/09/10/instance-init-realize.html > - should the irq state be in vmstate? I guess you mean the "uint32_t int_status;" field here? If it's state that's in your device then it needs to be in vmstate (this roughly corresponds to 'is there a flipflop in the hardware that holds this state', though that is not a 100% perfect guide). A 'qemu_irq' holds no state of its own, so you cannot query it for the state of the line after migration. So if your device model needs to be able to know that state itself then it has to keep it in a struct field and migrate that struct field. (For some devices the state of the outbound interrupt line is a purely combinatorial result of some other state: "int_output = int_status & int_mask" is a common one where there's a "raw interrupt status" and a mask bit that suppresses the outbound irq line. In that case the int_output need not be in the device's state struct or migrated, because we can just calculate it when we need it from the int_status and int_mask state.) > - is there a better way to do composition of classes (patch 3)? No strong opinion. From a quick scan through of patch 3 it didn't look obviously doing something in a suboptimal way. thanks -- PMM
