Hannu Lyytinen

Also, shouldn't you get rid of hard coded value at https://github.com/seL4/camkes-vm/blob/ce598e47ef9df054e2d160bdd3fd51af07672686/components/VM_Arm/vm_common.camkes#L33 (and the other one on line 35 also)?

I'm working on generalizing that cross-VM connector. My intention is to support mapping as RAM and providing MMIO-style interface in addition to that PCI interface. So perhaps `crossvm.c` should not...

+1 for removing the init_ram module. But can we make it a weak function, so that VMs could use custom code for overriding how the RAM is mapped? If you...

> @hlyytine What do you think about this implementation? Looks good to me now.

> @hlyytine I've added a commit that makes the DTB generation more dynamic, so modules can also add data to it. Would this allow you to implement youe use case,...

I got a bit hesitant about using `ram_size == 0` notion to disable init_ram module functionality. I think that even we, those familiar with the code, should not rely on...

I got even simpler idea: seems that we all agree RAM is needed from VM in any case, which means linker must be able to resolve `ram_base` and `ram_size`. Wouldn't...

> I think this was actually why the init_ram module was made. This example uses a ram dataport to introspect a guest VMs ram device: https://github.com/seL4/camkes-vm-examples/blob/master/apps/Arm/vm_introspect/src/init_dataport_ram.c#L39-L45 Thanks for reminding. Funny...

> I also am not sure about the motivation of this PR is as the module was added for the vm_introspect example to perform its own ram installation. The trouble...

@axel-h IMO inlining this would be good, as the weak function kind of negates the purpose of the module system. But how about if you just copied & pasted that...