Re: Plugin Address Translations Inconsistent/Incorrect?

[Peter Maydell]

On Tue, 23 Feb 2021 at 08:55, Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > On Mon, 22 Feb 2021 at 19:53, Alex Bennée <alex.bennee@linaro.org> wrote:
> >> It certainly is by design. The comment for the helper states:
> >>
> >>   /*
> >>    * The following additional queries can be run on the hwaddr structure
> >>    * to return information about it. For non-IO accesses the device
> >>    * offset will be into the appropriate block of RAM.
> >>    */
> >
> > That sounds like we're exposing ram_addrs to the plugin. Are we?
> > I'm not sure that's a good idea, as they're not a guest-relevant
> > construct.
>
> We currently expose qemu_ram_addr_from_host for RAM blocks. Are you
> saying we should translate that to the direct physical address mapping?
> If we do that for RAM should we be doing the same for IO addresses

This is not a fully-thought-through position, but as a general
thing I feel that the plugin API should be exposing as far as
possible concepts that relate to the guest program, not concepts
that relate to QEMU's internal implementation. One of the issues
with the -d logging is that it's very much "provide information
that's easy for QEMU to provide", and this confuses people who
just want to debug their guest. We can reasonably expect users to
understand concepts like "physical address", but it's less nice
to need them to understand "QEMU models guest RAM as a bunch of
blocks with a 'ram address' which is an offset into the stack
of blocks, and this isn't the same thing as any guest address".
It also constrains our ability to change the QEMU implementation
later if we let implementation details leak out via the plugin API.

thanks
-- PMM