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

[David Gibson]

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