From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROKWz-0002Fb-4l for qemu-devel@nongnu.org; Wed, 09 Nov 2011 21:38:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ROKWx-0001iP-Mi for qemu-devel@nongnu.org; Wed, 09 Nov 2011 21:38:21 -0500 Received: from mail-qy0-f173.google.com ([209.85.216.173]:59503) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROKF4-000772-JM for qemu-devel@nongnu.org; Wed, 09 Nov 2011 21:19:50 -0500 Received: by qyk30 with SMTP id 30so7132866qyk.4 for ; Wed, 09 Nov 2011 18:19:49 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4A2D3614-438C-40F4-B3D1-A8ABF30FB82F@suse.de> References: <1320887981-2099-1-git-send-email-agraf@suse.de> <4A2D3614-438C-40F4-B3D1-A8ABF30FB82F@suse.de> Date: Thu, 10 Nov 2011 02:19:48 +0000 Message-ID: From: Peter Maydell Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH] s390x: initialize virtio dev region List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: qemu-devel@nongnu.org On 10 November 2011 01:45, Alexander Graf wrote: > On 10.11.2011, at 02:36, Peter Maydell wrote: >> This looks a bit fishy -- cpu_physical_memory_map() takes a >> target_phys_addr_t but you're passing it a ram_addr_t. > > Meh. Always those types ... :) In the simple case ("ram starts at 0, not multiply mapped, guest and host pointer widths the same") target_phys_addr_t's and ram_addr_t's are the same, but this isn't necessarily so; indeed one ram_addr_t can be mapped to multiple target_phys_addr_t's in some system models. So the two things aren't trivially interconvertible. (As it happens I think in this case you're actually just doing physical address calculations using the wrong type...) > On 10.11.2011, at 02:36, Peter Maydell wrote: >> Also isn't this second-guessing the ram_addr_t of the region allocated >> inside memory_region_init_ram() ? > > Not sure I understand? On s390-virtio we have to following ram layout: > > [ ----- RAM ---- | --- virtio device structs --- ] > > The size of the latter is added to my_ram_size by > s390_virtio_bus_init. All I'm trying to do is make sure that this > latter part of RAM is always 0, while the first part can still be > dynamically allocated. That comment was written on the assumption that you were actually trying to manipulate a ram_addr_t in your variable of type ram_addr_t; to expand on it a bit: I think that conceptually the only way to get the ram_addr_t for a bit of RAM should be that you got it back from qemu_ram_alloc() (or that you did the obvious arithmetic to get a ram_addr_t within a block given the start of one). As it happens qemu_ram_alloc() starts ram_addr_t's at 0 and works up with no gaps, but that's an implementation detail. (Also if anybody ever did something that meant there was another qemu_ram_alloc() call before the one done inside that memory_region_init_ram() then things would break.) In summary, either: (1) you need to ask the memory region for its ram_addr_t [there doesn't seem to be an API for this at the moment], do arithmetic on ram_addr_t's and use qemu_get_ram_ptr() to get a host pointer corresponding to that ram_addr_t or (2) you need to do your arithmetic in target_phys_addr_t's (and then you can say your RAM starts at physaddr 0, which is guaranteed, rather than at ram_addr_t 0, which isn't) and use cpu_physical_memory_map/unmap(). -- PMM