[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: [PATCH 4/5] exec.c: refactor cpu_physical_memory_map
On Wed, 18 May 2011, Paolo Bonzini wrote: > On 05/18/2011 07:52 PM, stefano.stabellini@xxxxxxxxxxxxx wrote: > > From: Stefano Stabellini<stefano.stabellini@xxxxxxxxxxxxx> > > > > Introduce qemu_ram_ptr_length that takes an address and a size as > > parameters rather than just an address. > > > > Refactor cpu_physical_memory_map so that we call qemu_ram_ptr_length only > > once rather than calling qemu_get_ram_ptr one time per page. > > This is not only more efficient but also tries to simplify the logic of > > the function. > > Currently we are relying on the fact that all the pages are mapped > > contiguously in qemu's address space: we have a check to make sure that > > the virtual address returned by qemu_get_ram_ptr from the second call on > > is consecutive. Now we are making this more explicit replacing all the > > calls to qemu_get_ram_ptr with a single call to qemu_ram_ptr_length > > passing a size argument. > > Would the interface at > http://permalink.gmane.org/gmane.comp.emulators.qemu/101475 work for you > alternatively? Unfortunately that interface doesn't solve the problem I am trying to address: cpu_physical_memory_map_fast calls cpu_physical_memory_map_internal that still calls qemu_get_ram_ptr in a loop. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |