This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[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

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