On 10 July 2017 at 11:16, Ormaetxea Xabier <xormaet...@ikerlan.es> wrote: > Ah sorry, I thought that replying to your message it was somehow > redirected to the mailing list. So, every-time I respond, I have > to do it to qemu-devel@nongnu.org? Or a CC it's enough? Sorry for > my ignorance...
Yes, you just have to send mail to: or cc: the qemu-devel address. > Anyway, do you imagine how can I make this "virtual world"-"real world" > connection? I mean, is there an easy way of connecting an execution > from the standalone with the source code? Two things: (1) you should try to make your interface with the emulator map more closely to what existing examples do. "Write to a virtual address in RAM that is monitored" is really weird and will be a pain to implement. What makes more sense depends a bit on whether you're using qemu-system-* (a full-system emulator of cpu and devices) or qemu-* (which just emulate a single Linux process by intercepting system calls). For full-system, you can for instance provide a device model that sits at a known physical address. Or you can use the kind of interface that OSes might use to talk to firmware (like an SMC instruction on ARM -- our PSCI implementation works this way). For linux-user the simplest thing is obviously just to implement a syscall (or to use the existing timer ones!) (2) you don't want to do this by "check something every time round an execution loop" because this will make the performance very bad. What you need to do is arrange that when the guest does some action (write to physical address, make SMC call, make system call) you get control and can implement your behaviour there. (This is another reason why write-to-virtual-address is a suboptimal choice: it's harder to get control for that.) thanks -- PMM
