: Generic memory callback regions

Hi,

This patch adds an API for CONFIG_SOFTMMU mode that hardware drivers can use to add memory regions backed by callback functions. It simply adds a layer for storing opaque data above the basic cpu_register_io_memory / cpu_register_physical memory functions. I used a linked list to store the data structures, i think O(ln/2) avg. lookup time will be fine as I don't envisage many of these regions existing.

I've tested it as far as I currently can for the pciproxy code and it seems to do the correct thing. I could work around this manually within the pciproxy code itself, but I figured a generic interface would be something useful for other drivers (such as any PCI card with MMIO resources).

Ideas / thoughts / bugs?

// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

diff -urN qemu.orig/cpu-all.h qemu.callback_mem/cpu-all.h
@@ -680,10 +680,28 @@
 #define IO_MEM_UNASSIGNED  (2 << IO_MEM_SHIFT)
 #define IO_MEM_CODE        (3 << IO_MEM_SHIFT) /* used internally, never use directly */
 #define IO_MEM_NOTDIRTY    (4 << IO_MEM_SHIFT) /* used internally, never use directly */
+#define IO_MEM_CALLBACK    (5 << IO_MEM_SHIFT) /* Callback functions */
 
 typedef void CPUWriteMemoryFunc(target_phys_addr_t addr, uint32_t value);
 typedef uint32_t CPUReadMemoryFunc(target_phys_addr_t addr);
 
+typedef void (*CPUWriteMemoryCallback)(void *opaque,
+                                    target_phys_addr_t addr,
+				    int len,
+                                    uint32_t val);
+typedef uint32_t (*CPUReadMemoryCallback)(void *opaque,
+                                    target_phys_addr_t addr,
+				    int len);
+
+int cpu_register_callback_memory(target_phys_addr_t start_addr,
+                                  unsigned long size,
+				  CPUReadMemoryCallback mem_read,
+				  CPUWriteMemoryCallback mem_write,
+				  void *opaque);
+int cpu_unregister_callback_memory(target_phys_addr_t start_addr,
+                                  unsigned long size);
+
+
 void cpu_register_physical_memory(target_phys_addr_t start_addr, 
                                   unsigned long size,
                                   unsigned long phys_offset);

I haven't read your patch, but I recently wrote a SH2 emulator. We found that a lot of time was spent finding the right callbacks, so for the device memory, we used a sorted array. After each access, we bubbled that memory region closed to the beginning of the array. This turned out to be faster than the tree that we were using. The main differences are we have 100+ regions and implemented it in Java.

Joe

Good call. Move-to-front heuristic seems smart because I anticipate (and you found out for real) that memory accesses will have temporal locality. Moving to head is theoretically the same or a little better than 'bubbling up' actually, Knuth covers it in Vol 3 as i recall.

Well, it becomes irrelevent for this case now, as I am implementing this privately in pciproxy.c, rather than publically in exec.c, and in my case the list is always 1 item long :)

// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D