Re: [Qemu-ppc] [Qemu-devel] [PATCH RFC qom-cpu 04/41] cpu: Introduce CPUClass::set_pc() for gdb_set_cpu_pc()

[Peter Maydell]

On 1 July 2013 20:03, Richard Henderson <address@hidden> wrote:
> I would think hwaddr wouldn't be appropriate, since that's supposed to be
> talking about physical addresses, and that's not the case here.  The name (and
> admittedly minimal documentation for) ram_addr_t sounds right, but it seems to
> be sized wrong, so I don't know what it's actually supposed to be.

ram_addr_t is for indexes into guest RAM, ie into what you get by concatenating
all the RAMBlocks together. (This is why it's uintptr_t sized -- you know you
can't have more RAM total than will fit into the host's address space.)
It usually isn't what you want. Feel free to suggest improvements to
HACKING -- I tried to describe this in the bit that goes "ram_addr_t is
a QEMU internal address space ..." but since I already knew what it did
I probably failed to explain sufficiently.

Returning to the point, what we're after here is "a type which will hold
a guest virtual address but whose size doesn't depend on the target the
way target_ulong does", right? My inclination is to suggest that we have
a 'vaddr' typedef by analogy with 'hwaddr'; it seems like that might make
code dealing with guest addresses a little more self documenting. I don't
feel very strongly about it though so if people think it's pointless/will
cause problems that's fine.

thanks
-- PMM