[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

  • To: stefano.stabellini@xxxxxxxxxxxxx
  • From: Paolo Bonzini <pbonzini@xxxxxxxxxx>
  • Date: Wed, 18 May 2011 23:56:56 +0200
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, qemu-devel@xxxxxxxxxx, agraf@xxxxxxx
  • Delivery-date: Wed, 18 May 2011 14:58:43 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:newsgroups:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; b=tLBcE5XJFADlGwv9FYQ+C/BwPpihoB+OnfnHDifcazFXVywhhO69Zoxqiknh69I8xy nW+phm6dDz9tYPz6PMmJ0BpAYtcDpdGJOjXMvdCGLEdmVkMUUlNZWyIFFxieMzCmIKZv 8CMOdKUuJUq0u+uEN6qEGFr6vsUgvp/GYvOuw=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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?


Xen-devel mailing list



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