[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.