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

[Blue Swirl]

On Sun, Oct 30, 2011 at 14:19, Avi Kivity <address@hidden> wrote:
> On 10/30/2011 04:12 PM, 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.
>>>
>>> It has been argued that with careful coding we can make 64-bit work as
>>> well.  I don't think this is true in general - a memory router can
>>> adjust
>>> addresses either forwards or backwards, and some buses (PCIe) need the
>>> full 64-bit space - though it's probably the case for all the
>>> configurations
>>> we support today.  Regardless, the need for careful coding means
>>> subtle bugs,
>>> which I don't want in a core API that is driven by guest supplied
>>> values.
>>
>> The primary need for signed arithmetic is aliases, correct?
>
>> Where do we actually make use of this in practice?   I think having
>> negative address spaces is a weird aspect of the memory api and wonder
>> if refactoring it away is a better solution tot he problem.
>>
>
> There is no direct use of signed arithmetic in the API (just in the
> implementation).  Aliases can cause a region to move in either the
> positive or negative direction, and this requires either signed
> arithmetic or special casing the two directions.
>
> Signed arithmetic is not the only motivation - overflow is another.
> Nothing prevents a user from placing a 64-bit 4k BAR at address
> ffff_ffff_ffff_f000; we could move to base/limit representation, but
> that will likely cause its own bugs.  Finally, we should be able to
> represent both a 0-sized region and a 2^64 sized region.

It looks like 64 bit saturating arithmetic could also work. It should
also be possible to work only with (start, end) address pairs and
never with start + size, then 2^64 shouldn't be an issue.