[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PULL 0/3] 128-bit support for the memory API
From: |
Avi Kivity |
Subject: |
Re: [Qemu-devel] [PULL 0/3] 128-bit support for the memory API |
Date: |
Sun, 30 Oct 2011 16:19:51 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0 |
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.
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PULL 0/3] 128-bit support for the memory API, Anthony Liguori, 2011/10/31