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 properly represent the entire address space.
Or, indeed, anything in the second half of it.
I don't think there's any cpu which has a real 64-bit physical address
space? Don't they all truncate it?
It sounds like your problem would be better solved by re-arranging
things such that you perform X< Y comparisons rather than DELTA< 0.
More like, X + delta < Y + delta, I just get a headache what all those
deltas mean everywhere.
For reference, the root cause is
static void render_memory_region(FlatView *view,
MemoryRegion *mr,
target_phys_addr_t base,
AddrRange clip)
{
...
base += mr->addr;
...
if (mr->alias) {
base -= mr->alias->addr;
base -= mr->alias_offset; // <--- HERE!
render_memory_region(view, mr->alias, base, clip);
return;
}
I could pass alias_offset everywhere and compensate for it. But
stealing bit from the address space is easier than adjusting all the
calculations.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
