On 12/22/08, Glauber Costa <[email protected]> wrote: > >> It really does though. The way physical memory is registered and managed > >> is TCG specific right now. It has deep hooks for invalidating > >> TranslationBlock's, and the table structure is designed to be conducive to > >> the access patterns of TCG. > > > > Yes, but also dyngen stuff used the same structures, so it's a bit > > more generic than TCG-only. > > yeah, but dyngen is gone now. So tcg really stands for "whatever qemu > does", in here.
But something new can still come and replace TCG. > >> If you think of a higher level CPU API, I think registering physical > memory > >> and reading/writing physical memory would end up being part of that API. > > > > Thanks, I was looking for something like this. CPU emulator is more > > than just TCG or dyngen and it is also ~KVM. So how about > > cpu_emu_register_physical_memory_offset? > > > > Also noaccel_register_physical_memory_offset would fit. > > After this revision, I must say I'm less happy with the name "accel". > It's really a cpu model. I'm even thinking about changing the name of it > to QEMUCPUModel or whatever. (suggestions welcome) > > So "default" or "qemu" would be good choices IMHO. I vote for "default". -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
