Re: Replace calls to functions named cpu_physical_memory_* with address_space_*.

[Tanmay]

Yeah, I felt that it may not be a cakewalk as it might sound.

You're right, trying to understand the whole code is overwhelming. I'll start with a small section instead.

I have interest in working on x86_64 and Aarch64 architectures within qemu.

Please let me know if there are any specific tasks from where I can start exploring.

Thanks,

Tanmay

On Thu, 26 Oct 2023 at 22:16, Peter Maydell <peter.maydell@linaro.org> wrote:

On Thu, 26 Oct 2023 at 13:48, Tanmay <tanmaynpatil105@gmail.com> wrote:
> I'm really interested in contributing to qemu. I wanted to
> work on the renaming API calls cpu_physical_memory_* to
> address_space_*. I couldn't find any related issues on the
> GItlab tracker. Can I work on this issue?

You're welcome to, but be aware that this is unfortunately
one of the items in the "BiteSizedTasks" list that is
not as simple as the one-line description makes it sound.
(I have a personal project to try to go through that page and
either expand entries into issues in gitlab that describe the
task in more detail, or else delete them if they don't really
seem to be "bite sized". But I haven't got very far with it yet,
so there are still quite a few unhelpful "landmine" tasks on it.
Sorry about that :-(  )

It also is something where the right thing to do is going to
depend on the call-site and what that particular device or piece
of code is trying to do -- it is not a mechanical conversion.
(This is partly why the conversion is not yet complete.)

Most of the devices which use these functions should indeed
use address_space_* functions instead, but the question then
is "what address space should they access?". That usually ought
to be one passed into them by the board code. (commit 112a829f8f0a
is an example of that kind of conversion.) Unfortunately many
of the remaining uses of cpu_physical_memory_* in hw/ are
in very old code which hasn't even been converted to the
kind of new device model coding style that would allow you to
provide an address space by a QOM property that way. So for
those devices this would be just one of a whole pile of
"modernizations" and refactorings that need to be done.

I think what I would suggest is that rather than starting
with this task in general, that you start with what part
of QEMU you're interested in working on in particular (eg
whether you're interested in a particular target architecture
or a particular subsystem like migration, etc), and then
we can probably find some tasks that relate to that specific
interest and help in starting to understand that part of the
code. (QEMU as a whole is too big for anybody to understand
all of it...) If what you want to work on turns out to
involve one of the bits of code which needs this API upgrade,
maybe we can help you work on that; but it might turn out that
the two don't overlap at all, or that there's a better starting
task.

thanks
-- PMM