From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JM3IR-00022c-Mi for qemu-devel@nongnu.org; Mon, 04 Feb 2008 10:31:47 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JM3IP-00021P-PY for qemu-devel@nongnu.org; Mon, 04 Feb 2008 10:31:46 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JM3IP-00021K-Hu for qemu-devel@nongnu.org; Mon, 04 Feb 2008 10:31:45 -0500 Received: from fk-out-0910.google.com ([209.85.128.185]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JM3IP-0001j0-Am for qemu-devel@nongnu.org; Mon, 04 Feb 2008 10:31:45 -0500 Received: by fk-out-0910.google.com with SMTP id 18so3733419fkq.2 for ; Mon, 04 Feb 2008 07:31:44 -0800 (PST) Message-ID: <47A72FD9.90606@codemonkey.ws> Date: Mon, 04 Feb 2008 09:31:37 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1201903921-1125-1-git-send-email-aliguori@us.ibm.com> <1201903921-1125-3-git-send-email-aliguori@us.ibm.com> <47A670B4.6020803@codemonkey.ws> <1202114748.30861.6.camel@localhost.localdomain> In-Reply-To: <1202114748.30861.6.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 2/6] Use correct types to enable > 2G support (v2) Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Izik Eidus Cc: kvm-devel@lists.sourceforge.net, Paul Brook , qemu-devel@nongnu.org Izik Eidus wrote: >> Do you recall what this change fixed? As Paul pointed out in IRC, using >> the host type here doesn't really fix the problem (target_ulong would be >> more appropriate). However, we're both curious what problem it's >> actually fixing since sign extending the int should just work. >> > > ok the commit say: > > kvm: qemu: change the type of the various page masks to unsigned long > > prevents truncation with >=4GB of guest physical memory > > > as far as i remember it was used to address something with > cpu_physical_memory_rw() probably related to &TARGET_PAGE_SIZE > or ~TARGET_PAGE_SIZE, > > the fact is that i dont know if it ever fixed anything > Thanks, that was my suspicion too. Regards, Anthony Liguori