On 12/19/08, Anthony Liguori <[email protected]> wrote: > Blue Swirl wrote: > > > On 12/18/08, Glauber Costa <[email protected]> wrote: > > > > > > > Since now we have our own memory read/write function, we don't > > > depend on all of tcg data structures anymore. So, instead of filling > > > them up, bypass it altogether by using kvm_set_phys mem alone. > > > > > > To do that, we now have to provide our own way to get page > > > information given the address. (kvm_get_physical_page_desc) > > > > > > Signed-off-by: Glauber Costa <[email protected]> > > > > > > > > > > > > > > > +static void > tcg_register_physical_memory_offset(target_phys_addr_t > start_addr, > > > > > > > > > > I don't think TCG actually has much to do with the function. > > > > 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. > 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. -- 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
