From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47768) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROtuA-0007s5-KS for qemu-devel@nongnu.org; Fri, 11 Nov 2011 11:24:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ROtu9-0005We-Fx for qemu-devel@nongnu.org; Fri, 11 Nov 2011 11:24:38 -0500 Received: from cantor2.suse.de ([195.135.220.15]:40229 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROtu9-0005WN-64 for qemu-devel@nongnu.org; Fri, 11 Nov 2011 11:24:37 -0500 Message-ID: <4EBD4C57.1080709@suse.de> Date: Fri, 11 Nov 2011 17:24:55 +0100 From: Alexander Graf MIME-Version: 1.0 References: <1320887981-2099-1-git-send-email-agraf@suse.de> <4A2D3614-438C-40F4-B3D1-A8ABF30FB82F@suse.de> <4EBD467F.7040107@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] s390x: initialize virtio dev region List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel@nongnu.org On 11/11/2011 05:11 PM, Peter Maydell wrote: > On 11 November 2011 15:59, Alexander Graf wrote: >> This is the machine init function. The s390 virtio machine's ram layout is >> defined to be exactly as I posted in the previous post. So there won't be >> any ram starts at != 0 or multiple mappings :). > That's the layout of the RAM in target_phys_addr_t space. > The layout of the ram in ram_addr_t space is not guaranteed > to be the same, it just happens to be in this case. > >>>> On 10.11.2011, at 02:36, Peter Maydell wrote: >>> 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(). >> I still don't get it. What I want is: >> >> for (i = ram_size; i< my_ram_size; i++) >> stb_phys(env, i, 0); >> >> cpu_physical_memory_map gives me a pointer to the memory region between >> ram_size and my_ram_size. I memset(0) it. I don't see how I could possibly >> have different offsets anywhere. If cpu_physical_memory_map would take >> anything different than physical address, a lot of assumptions in QEMU code >> would break. > Yes, so that's option (2) and you need to be using a target_phys_addr_t. But ram_size is ram_addr_t and is the ram size that I have available to use, so it's exactly the address that I want. I don't see your point. Should go jump through random useless hoops of doing target_phys_addr_t ram_end = ram_size; just because there are some subtile semantic differences between the two variables? They're integers at the end of the day. Both of them. Alex