From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44127) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VFHzt-0004II-1L for qemu-devel@nongnu.org; Fri, 30 Aug 2013 02:16:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VFHzk-000264-AV for qemu-devel@nongnu.org; Fri, 30 Aug 2013 02:15:52 -0400 Received: from mail-pa0-f50.google.com ([209.85.220.50]:43099) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VFHzk-00025w-3o for qemu-devel@nongnu.org; Fri, 30 Aug 2013 02:15:44 -0400 Received: by mail-pa0-f50.google.com with SMTP id fb10so1915895pad.9 for ; Thu, 29 Aug 2013 23:15:43 -0700 (PDT) Message-ID: <52203889.40307@ozlabs.ru> Date: Fri, 30 Aug 2013 16:15:37 +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> <521EF0FD.5080906@ozlabs.ru> <521F0B5C.3090102@redhat.com> In-Reply-To: <521F0B5C.3090102@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 06:50 PM, Paolo Bonzini wrote: > Il 29/08/2013 08:58, Alexey Kardashevskiy ha scritto: >> 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? > > What if you just merge the two series together? It will still be a function which can accept sections bigger than 2^64 and theoretically call int128_get64() and assert. I would think that every time when anyone calls int128_get64(), the value should be checked for <2^64. It is like division by zero :) -- Alexey