On Mon, 5 Mar 2012, Blue Swirl wrote: > 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? Heh, a_moo would be Malced, no _t is Posixed indeed. -- mailto:av1474@xxxxxxxx
