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
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 right that
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
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 converted
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: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
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