From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35792) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZucVo-0006mC-WD for qemu-devel@nongnu.org; Fri, 06 Nov 2015 03:36:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZucVk-0000aw-VC for qemu-devel@nongnu.org; Fri, 06 Nov 2015 03:36:44 -0500 Received: from e06smtp14.uk.ibm.com ([195.75.94.110]:51744) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZucVk-0000Zp-MU for qemu-devel@nongnu.org; Fri, 06 Nov 2015 03:36:40 -0500 Received: from localhost by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 6 Nov 2015 08:36:39 -0000 Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id AB6791B0805F for ; Fri, 6 Nov 2015 08:36:51 +0000 (GMT) Received: from d06av11.portsmouth.uk.ibm.com (d06av11.portsmouth.uk.ibm.com [9.149.37.252]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id tA68aam24325658 for ; Fri, 6 Nov 2015 08:36:37 GMT Received: from d06av11.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av11.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id tA68aabo000860 for ; Fri, 6 Nov 2015 01:36:36 -0700 References: <1446740339-31366-1-git-send-email-pmorel@linux.vnet.ibm.com> <563B8498.7070804@redhat.com> From: Pierre Morel Message-ID: <563C6695.7030507@linux.vnet.ibm.com> Date: Fri, 6 Nov 2015 09:36:37 +0100 MIME-Version: 1.0 In-Reply-To: <563B8498.7070804@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/7] int128: reparing broken 128 bit memory calculations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , qemu-devel@nongnu.org Cc: cornelia.huck@de.ibm.com, peter.maydell@linaro.org On 11/05/2015 05:32 PM, Paolo Bonzini wrote: > > On 05/11/2015 17:18, Pierre Morel wrote: >> The size of a memory area can never be negative. >> It follows it must be defined as an unsigned value. >> >> Let's modify the memory regions size to unsigned 128 integer >> and modify accordingly the 128 bit arithmetic. >> >> This makes memory size calculations easier and easier to understand. >> >> I fear loud protest but really, it is a broken concept that >> obfuscate the code. > You are right in fearing loud protest, though the protest is for the > lack of explanation of what is broken. > > Since the values are never going to be > 2^65, there is no chance of > overflow. On the other hand there are cases where we compute > start+size-1, and size-1 *could* overflow if you use unsigned integers. > > So I am not sure... why? > > Paolo > Paolo, The calculation are not broken and it works for actual usage but: For me, it is the design that is broken, as it uses an integer to represent something that is fundamentally unsigned like the size of a memory area. This leads to have UINT64_MAX represented with {1, 0} instead of {0, UINT64_MAX} while {1, 0} is 2^64. This again leads to have unnecessary and obfuscating transformations with int128_2_64() to test for UINT64_MAX and return {1,0} in memory_region_init() while using inverse translation test{1,0} and return UINT64_MAX in memory_region_size() Another concern is that pushing the 31th bit to the 32nd bit may be confusing when used, if ever, with IOMMU or other hardware components using 128bits registers. Considering some Intel IOMMU for example. The modifications I proposed are also not perfect, I just seen I forgot to change a -1 to UINT64_MAX and I forgot some unnecessary cast. At least. Pierre