On Wed, 2011-08-03 at 11:26 +0300, Avi Kivity wrote:
> On 08/03/2011 01:15 AM, Richard Henderson wrote:
> > On 08/02/2011 03:06 PM, Avi Kivity wrote:
> > > I don't think there's any cpu which has a real 64-bit physical
> > > address space? Don't they all truncate it?
> >
> > I don't know. You're
On 08/03/2011 01:15 AM, Richard Henderson wrote:
On 08/02/2011 03:06 PM, Avi Kivity wrote:
> I don't think there's any cpu which has a real 64-bit physical
> address space? Don't they all truncate it?
I don't know. You're right that x86_64 does, at 48 bits.
The alpha system I'm trying to emul
On 08/02/2011 03:06 PM, Avi Kivity wrote:
> I don't think there's any cpu which has a real 64-bit physical
> address space? Don't they all truncate it?
I don't know. You're right that x86_64 does, at 48 bits.
The alpha system I'm trying to emulate does, at 50 bits.
I guess if IBM agrees wrt p-se
On 08/03/2011 12:59 AM, Richard Henderson wrote:
On 08/02/2011 01:50 PM, Avi Kivity wrote:
> struct AddrRange {
> -uint64_t start;
> -uint64_t size;
> +int64_t start;
> +int64_t size;
I'm must say I'm not keen on this. My primary objection is that
a "range" can no longer p
On 08/02/2011 01:50 PM, Avi Kivity wrote:
> struct AddrRange {
> -uint64_t start;
> -uint64_t size;
> +int64_t start;
> +int64_t size;
I'm must say I'm not keen on this. My primary objection is that
a "range" can no longer properly represent the entire address space.
Or, indeed,
On 08/03/2011 12:15 AM, malc wrote:
On Tue, 2 Aug 2011, Avi Kivity wrote:
> When trying to map an alias of a ram region, where the alias starts at
> address A and we map it into address B, and A> B, we had an arithmetic
> underflow. Because we use unsigned arithmetic, the underflow converte
On Tue, 2 Aug 2011, Avi Kivity wrote:
> When trying to map an alias of a ram region, where the alias starts at
> address A and we map it into address B, and A > B, we had an arithmetic
> underflow. Because we use unsigned arithmetic, the underflow converted
> into a large number which failed addr
