On Sun, Oct 30, 2011 at 04:19:51PM +0200, Avi Kivity 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.
You keep saying we need signed arithmetic for this, but it's not
really true. *If* you see aliases as shifting the entire aliases
address space w.r.t., then just allowing a window to show through, you
get negative offsets, yes, but that's by no means the only way t think
about it.
It's basically one spot - the alias handling in render_memory_region()
- that generates a negative start intermediate. I'm convinced it's
pretty straightforward to remove this - making a patch for it just
hasn't bubbled to the top of my priority queue, though.
> 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.
Note that an (inclusive) start/end representation also cannot
represent a 0 sized region.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
