Re: [PATCH v14 08/10] Adding info [tb-list|tb] commands to HMP (WIP)

[Wu, Fei]

On 6/8/2023 5:23 PM, Peter Maydell wrote:
> On Thu, 8 Jun 2023 at 08:44, Wu, Fei <fei2.wu@intel.com> wrote:
>>
>> On 6/7/2023 8:49 PM, Wu, Fei wrote:
>>> On 6/1/2023 10:40 AM, Richard Henderson wrote:
>>>> Did you really need something different than monitor_disas?  You almost
>>>> certainly want to read physical memory and not virtual anyway.
>>>>
>>> Yes, it's usually okay for kernel address, but cannot re-gen the code
>>> for userspace virtual address (guest kernel panic on riscv guest). I
>>> tried monitor_disas() but it failed to disas too:
>>>     monitor_disas(mon, mon_get_cpu(mon), tbs->phys_pc, num_inst, true);
>>>
>>> How to use this function correctly?
>>>
>> 'phys_pc' in tbs is returned by get_page_addr_code_hostp(), which is not
>> guest phys address actually, but ram_addr_t instead, so it's always
>> wrong for monitor_disas. After some dirty changes, tbs can record the
>> guest pa. Now we can disas both kernel and user space code. But still,
>> no code is regenerated, disas in 'info tb' is just a convenient way to 'xp'.
>>
>> Is there any existing function to convert ram_addr_t to guest pa?
> 
> Such a function would not be well-defined, because a block of RAM
> as specified by a ram_addr_t could be present at (aliased to) multiple
> guest physical addresses, or even currently not mapped to any guest
> physical address at all. And it could be present at different physical
> addresses for different vCPUs.
> 
Thank you, Peter. What's the scenario of the last different physical
addresses for different vCPUs?

For this specific case, I found I don't have to convert ram_addr_t to
gpa, the real requirement is converting ram_addr_t to hva, this one
seems well defined using qemu_map_ram_ptr(0, ram_addr) ?

Thanks,
Fei.

> thanks
> -- PMM