Re: [Qemu-devel] [RFC v2 01/20] Hierarchical memory region API

[Avi Kivity]

On 06/28/2011 04:25 PM, Peter Maydell wrote:
> On 28 June 2011 13:09, Avi Kivity<address@hidden>  wrote:
> >  Okay, let's make t_p_a_t max(bus size in system).
>
> If you want a type for that, can't you give it a sensible (ie
> different) name? target_phys_addr_t is pretty clearly "the type
> of a physical address for this target" and having it actually
> be something else is just going to be confusing.

"a physical address" is ambiguous.  There are many physical addresses 
flowing around.  Certainly it's most natural to think about the 
processor's physical address bus, but that's not always useful.

Since all *devices* use target_phys_addr_t, I think we should just adopt 
that to avoid major and pointless churn.

> >  Do we have 32-bit targets
> >  that don't support pci (I guess, pc-isa with cpu<  ppro?).  Do we want to
> >  support a 32-bit variant of pci?  It certainly existed at some point.
>
> As a thought experiment, you could take an existing 32 bit
> target and define a new board model that happens to have eg a
> new pci controller on it. It doesn't seem right that that
> should cause the system's idea of this type width to change,
> it's just a new device model and board. So if you have this
> type I think it ought to be max(bus size of widest bus qemu
> supports).

That indicates

  typedef uint64_t target_phys_addr_t;

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