From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51876) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUkMM-0000dD-Fp for qemu-devel@nongnu.org; Tue, 23 Apr 2013 17:02:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UUkMH-0000F1-LA for qemu-devel@nongnu.org; Tue, 23 Apr 2013 17:02:42 -0400 Received: from mail-qc0-x22b.google.com ([2607:f8b0:400d:c01::22b]:43304) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUkMH-0000Ew-HA for qemu-devel@nongnu.org; Tue, 23 Apr 2013 17:02:37 -0400 Received: by mail-qc0-f171.google.com with SMTP id q2so567971qch.2 for ; Tue, 23 Apr 2013 14:02:37 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5176F6DE.8080709@redhat.com> Date: Tue, 23 Apr 2013 23:02:22 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1366705795-24732-1-git-send-email-imammedo@redhat.com> <1366705795-24732-18-git-send-email-imammedo@redhat.com> <5176C15E.9050106@redhat.com> <5176C766.7070706@siemens.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 17/21] introduce memory_region_get_address() and use it in kvm/ioapic List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: "kwolf@redhat.com" , "aliguori@us.ibm.com" , "ehabkost@redhat.com" , "gleb@redhat.com" , "mst@redhat.com" , Jan Kiszka , "quintela@redhat.com" , claudio.fontana@huawei.com, "qemu-devel@nongnu.org" , "aderumier@odiso.com" , "lcapitulino@redhat.com" , "blauwirbel@gmail.com" , "anthony.perard@citrix.com" , "alex.williamson@redhat.com" , "kraxel@redhat.com" , "yang.z.zhang@intel.com" , "stefano.stabellini@eu.citrix.com" , "armbru@redhat.com" , "rth@twiddle.net" Il 23/04/2013 20:00, Peter Maydell ha scritto: > For ARM we defer the mechanics of "tell the kernel where this memory > region is" from the device implementation (hw/intc/arm_gic_kvm.c) to > generic code in target-arm/kvm.c, which I personally think is a > neat way to solve this problem. Yes, it is. > NB: I don't think we should call it memory_region_get_address() > though -- that implies a non-existent parallel to the current > memory_region_set_address(). Hmm, good point. address_space_get_region_addr()? Paolo