Re: [Qemu-devel] KVM call agenda for tuesday 31

[Blue Swirl]

On Mon, Mar 5, 2012 at 15:17, Avi Kivity <address@hidden> wrote:
> On 03/05/2012 05:15 PM, Anthony Liguori wrote:
>>> The other alternative is to s/target_phys_addr_t/uint64_t/ in the memory
>>> API.  I think 32-on-32 is quite rare these days, so it wouldn't be much
>>> of a performance issue.
>>
>>
>> I think this makes sense independent of other discussions regarding
>> fixing target_phys_addr_t size.
>>
>> Hardware addresses should be independent of the target.  If we wanted
>> to use a hw_addr_t that would be okay too.
>>
>
> Would this hw_addr (s/_t$//, or you'll be Blued) be fixed at uint64_t

Malced? Posixed?

> (and thus only documentary), or also subject to multiple compilation?

In real world CPU physical addresses, bus addresses and device
addresses need not have anything in common. The best would be if we
could have devices with 10-bit addresses mixing freely with 32 bit
buses and 36 bit CPU physical addresses. The next best thing probably
is to fix all of them to shortest possible reasonable value, like now.
Fixing all of them to 64 bits would simplify things a lot if we no
longer care about the small performance loss on 32 bit hosts.

> --
> error compiling committee.c: too many arguments to function
>
>