* Peter Maydell (peter.mayd...@linaro.org) 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.
True, but isn't there a similar mechanism for when an MCE happens in the host memory? Dave > thanks > -- PMM -- -----Open up your eyes, open up your mind, open up your code ------- / Dr. David Alan Gilbert | Running GNU/Linux | Happy \ \ dave @ treblig.org | | In Hex / \ _________________________|_____ http://www.treblig.org |_______/
