Re: [Qemu-devel] [PULL 0/3] 128-bit support for the memory API

["Andreas Färber" <afaerber@suse.de>]

Am 01.11.2011 13:59, schrieb Anthony Liguori:
> 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.

FWIW I must say I don't like where this is heading... iiuc just because
of a zero-or-full-64-bits issue with start+end we're doubling the
internal storage format for all memory ranges. If having the size
unsigned would eliminate the overflow issue at hand, can't we move the
signedness to some flag field instead?
I don't see a problem with using macros/inlines, just with the seemingly
unnecessary 128-bitness. In particular I'm thinking of ARM.

Since this seems to be addressing an overflow bug in ppc64, the
hard-freeze date shouldn't make us rush this IMO.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg