On Mon, Mar 5, 2012 at 15:17, Avi Kivity <avi@xxxxxxxxxx> 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 > > -- 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
