Re: [Qemu-devel] Is the return address of get_page_addr_code guest physical address?

[Steven]

On Fri, Aug 10, 2012 at 11:47 AM, Peter Maydell
<address@hidden> wrote:
> On 10 August 2012 03:11, Steven <address@hidden> wrote:
>> The function definition has a return address type tb_page_addr_t.
>> tb_page_addr_t get_page_addr_code(CPUArchState *env1, target_ulong addr)
>>
>> I am wondering is this address the guest physical address or the host
>> virtual address.
>
> In linux-user mode the returned address is the guest virtual address.
> In system mode it is a ram_addr_t. (the comment above the implementation
> says "the returned address is not exactly the physical address: it
> is the offset relative to phys_ram_base" but this is out of date I think).
> A ram_addr_t is neither a host address nor a guest physical address
> but it's closely related to a guest physaddr (you can think of it as
> if all the RAM in the system was put into a straight line and then the

My question is related to system mode.
Is the RAM you mean the guest physical address, which is a continuous
sequence of numbers beginning from 0 to the max of allocated RAM of
the guest?

> ram_addr_t is an index into that).

If the returned value of get_page_addr_code is the index to that
straight line, I am wondering if it is the guest physical address. For
example, a 512MB guest has two RAMBlocks
        block hva: 139980450037760, offset: 0, length: 536870912
        block hva: 139981262475264, offset: 537001984, length: 131072
Then I print out the value of pc and its phys_pc returned value from
get_page_addr_code in tb_gen_code(...).
        pc and phys_pc: 0x00000000000f207f  537075839
We can see that the phys_pc is within the second RAMBlock. So if we
consider the beginning of the RAM line is 0, the pays_pc value is the
offset to 0.
In other word the phys_pc is exactly the guest physical address. Is
this correct?

- Steven

>
>> If it it is the guest physical address, why does Qemu waste guest
>> physical space to store these address for tb? Thanks.
>
> I'm not sure what you're asking here. This function returns a
> physical address because we store TCG translated code blocks in
> a hash table indexed by guest physaddr. Given the information
> "the CPU is trying to execute code from this physaddr" we need to
> be able to find out whether we already have a code block translated
> for that. (there is also a fast code path so we can avoid doing
> a complete lookup from physaddr most of the time.)
>
> -- PMM