From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LD3TZ-0003bK-AH for qemu-devel@nongnu.org; Wed, 17 Dec 2008 15:58:37 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LD3TW-0003Zl-R3 for qemu-devel@nongnu.org; Wed, 17 Dec 2008 15:58:36 -0500 Received: from [199.232.76.173] (port=48476 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LD3TW-0003Ze-CW for qemu-devel@nongnu.org; Wed, 17 Dec 2008 15:58:34 -0500 Received: from mx2.redhat.com ([66.187.237.31]:54225) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LD3TV-0003xh-Qz for qemu-devel@nongnu.org; Wed, 17 Dec 2008 15:58:34 -0500 Date: Wed, 17 Dec 2008 19:00:59 -0200 From: Glauber Costa Message-ID: <20081217210059.GA19123@poweredge.glommer> References: <1229546822-11972-1-git-send-email-glommer@redhat.com> <1229546822-11972-2-git-send-email-glommer@redhat.com> <1229546822-11972-3-git-send-email-glommer@redhat.com> <1229546822-11972-4-git-send-email-glommer@redhat.com> <49496765.8000404@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49496765.8000404@codemonkey.ws> Subject: [Qemu-devel] Re: [PATCH 3/5] replace cpu_physical_memory_rw Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: stefano.stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, avi@redhat.com On Wed, Dec 17, 2008 at 02:56:05PM -0600, Anthony Liguori wrote: > Glauber Costa wrote: >> This patch introduces a kvm version of cpu_physical_memory_rw. >> The main motivation is to bypass tcg version, which contains >> tcg-specific code, as well as data structures not used by kvm, >> such as l1_phys_map. >> >> In this patch, I'm using a runtime selection of which function >> to call, but the mid-term goal is to use function pointers in >> a way very close to which QEMUAccel used to be. >> >> Signed-off-by: Glauber Costa >> --- >> exec.c | 13 +++++++++++-- >> kvm-all.c | 39 +++++++++++++++++++++++++++++++++++---- >> kvm.h | 2 ++ >> 3 files changed, 48 insertions(+), 6 deletions(-) >> >> diff --git a/exec.c b/exec.c >> index 04eadfe..d5c88b1 100644 >> --- a/exec.c >> +++ b/exec.c >> @@ -2938,8 +2938,8 @@ int cpu_physical_memory_do_io(target_phys_addr_t addr, uint8_t *buf, int l, int >> >> + >> +void kvm_cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf, >> + int len, int is_write) >> +{ >> + KVMSlot *mem; >> + KVMState *s = kvm_state; >> + int l; >> + >> + mem = kvm_lookup_slot(s, addr); >> + if (!mem) >> + return; >> + >> + if ((mem->phys_offset & ~TARGET_PAGE_MASK) >= TLB_MMIO) { >> + l = 0; >> + while (len > l) >> + l += cpu_physical_memory_do_io(addr + l, buf + l, len - l, is_write, mem->phys_offset); >> + } else { >> + uint8_t *uaddr = phys_ram_base + mem->phys_offset + (addr - mem->start_addr); >> + if (!is_write) >> + memcpy(buf, uaddr, len); >> + else >> + memcpy(uaddr, buf, len); >> + } >> +} >> > > I think this is a bit optimistic. It assumes addr..len fits entirely > within a slot. That's not necessarily the case though. I think you > should probably limit len to whatever is left in the slot, then if > necessary, (tail) recursively call kvm_cpu_physical_memory_rw. It makes sense.