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

[Dr. David Alan Gilbert]

* Peter Maydell (peter.maydell@linaro.org) 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.

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   |_______/