On Thu, 2019-09-12 at 09:09 +0100, Dr. David Alan Gilbert wrote: > > You're actually using the same trick of using > REPLY_ACK/need_reply to make it synchronous that set_mem_table does;
I don't think it's really the same - though arguably I could have spec'ed the inband signal to *require* an ACK. The way I did it relies on the REPLY_ACK extension. SET_MEM_TABLE actually specifies a 3-way handshake, qemu->device, device->qemu, qemu->device. > that makes sense - but then new calls are getting it to actually process > some data/commands on the ring itself? No, the calls (or more specifically the REPLY_ACK to them) are really in simulation to only acknowledge the interrupt (kick/call) signal has been received and accounted for on the simulation calendar, the actual processing happens when the calendar event is scheduled. johannes
