On 6/8/2023 5:23 PM, Peter Maydell wrote: > On Thu, 8 Jun 2023 at 08:44, Wu, Fei <fei2...@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
