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
