From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57725) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLDwF-0000j1-7e for qemu-devel@nongnu.org; Tue, 01 Nov 2011 08:59:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RLDwA-0001Ij-UR for qemu-devel@nongnu.org; Tue, 01 Nov 2011 08:59:35 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:57862) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLDwA-0001IT-S7 for qemu-devel@nongnu.org; Tue, 01 Nov 2011 08:59:30 -0400 Received: by ywb3 with SMTP id 3so8722175ywb.4 for ; Tue, 01 Nov 2011 05:59:30 -0700 (PDT) Message-ID: <4EAFED2E.8000009@codemonkey.ws> Date: Tue, 01 Nov 2011 07:59:26 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1319983368-21801-1-git-send-email-avi@redhat.com> <4EAEC75B.6020006@codemonkey.ws> <20111101005401.GC6895@truffala.fritz.box> <4EAFB13C.5090104@redhat.com> In-Reply-To: <4EAFB13C.5090104@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PULL 0/3] 128-bit support for the memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Blue Swirl , qemu-devel@nongnu.org On 11/01/2011 03:43 AM, Avi Kivity wrote: > On 11/01/2011 02:54 AM, David Gibson wrote: >> On Mon, Oct 31, 2011 at 11:05:47AM -0500, Anthony Liguori wrote: >>> On 10/30/2011 09:02 AM, Avi Kivity wrote: >>>> This somewhat controversial patchset converts internal arithmetic in the >>>> memory API to 128 bits. >>> >>> Given the level of controversy, what do you think about deferring >>> this to 1.1? >> >> If it's deferred then one of my rearrangements for the arithmetic must >> go in instead. These patches fix real bugs, that bite us on pseries. >> It's not the only way to fix those bugs, and probably not even my >> personally preferred way to fix them, but they need to be fixed >> _somehow_ for 1.0. > > Yes, plus if one of them is exploitable, then it's certainly a must for 1.0. Since it's just internal, I'll just pull this series and if we want to change it post 1.0, we can. Regards, Anthony Liguori