From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44586) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VEwBR-00064v-AP for qemu-devel@nongnu.org; Thu, 29 Aug 2013 02:58:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VEwBJ-0003QP-S9 for qemu-devel@nongnu.org; Thu, 29 Aug 2013 02:58:21 -0400 Received: from mail-pa0-f51.google.com ([209.85.220.51]:49156) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VEwBJ-0003QD-LS for qemu-devel@nongnu.org; Thu, 29 Aug 2013 02:58:13 -0400 Received: by mail-pa0-f51.google.com with SMTP id lf1so514810pab.24 for ; Wed, 28 Aug 2013 23:58:11 -0700 (PDT) Message-ID: <521EF0FD.5080906@ozlabs.ru> Date: Thu, 29 Aug 2013 16:58:05 +1000 From: Alexey Kardashevskiy MIME-Version: 1.0 References: <1377170965-9905-1-git-send-email-aik@ozlabs.ru> <1377170965-9905-4-git-send-email-aik@ozlabs.ru> <1377703099.10408.71.camel@ul30vt.home> <521E9DF5.9080709@ozlabs.ru> <1377740545.10408.145.camel@ul30vt.home> <521EB16F.9010303@ozlabs.ru> <521EEA64.7000708@redhat.com> In-Reply-To: <521EEA64.7000708@redhat.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 3/3] vfio: Fix 128 bit handling List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Peter Maydell , Alex Williamson , qemu-devel@nongnu.org On 08/29/2013 04:29 PM, Paolo Bonzini wrote: > Il 29/08/2013 04:26, Alexey Kardashevskiy ha scritto: >> >> Right. I was planning to add my IOMMU stuff right before calculating @end. > > But then the non-IOMMU stuff can just use int128_get64, no? So even if > this patch simply uses int128_get64, it is still a suitable basis for > adding IOMMU stuff. Suitable but ugly. What if before calling int128_get64, I test section->size if it is <2^64 and only then do RAM part of this function? > > Paolo > >> >>>> This patch is not maintainable. We're seemingly >>>> calculating the same value twice with no comment as to why. A hwaddr >>>> type end should be calculated from the Int128 rather than paying >>>> attention to rollover in one place but not another. Thanks, >> Yes, not maintainable... I guess I just have to convert @end to 128 bit as >> well to have things consistent. > -- Alexey