Replace calls to functions named cpu_physical_memory_* with address_space_*.

Replace calls to functions named cpu_physical_memory_* with address_space_*.

[Tanmay]

[-- Attachment #1: Type: text/plain, Size: 243 bytes --]

Hi,

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?

Thanks,
Tanmay Patil

[-- Attachment #2: Type: text/html, Size: 306 bytes --]

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

[Tanmay]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

Hi,

The above refactoring of functions was mentioned under API conversion at
https://wiki.qemu.org/Contribute/BiteSizedTasks .

Thanks,
Tanmay Patil

On Thu, 26 Oct 2023 at 15:54, Tanmay <tanmaynpatil105@gmail.com> wrote:

> Hi,
>
> 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?
>
> Thanks,
> Tanmay Patil
>

[-- Attachment #2: Type: text/html, Size: 900 bytes --]

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

[Peter Maydell]

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

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

[Tanmay]

[-- Attachment #1: Type: text/plain, Size: 2982 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 3671 bytes --]

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

[Thomas Huth]

On 26/10/2023 20.21, Tanmay wrote:
> 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.

If you want to get a basic understanding for the QEMU patch workflow, one of 
these should be easy enough for a start:

  https://gitlab.com/qemu-project/qemu/-/issues/373

  https://gitlab.com/qemu-project/qemu/-/issues/1827

(of course the work can also be limited to some few files, it doesn't have 
to be the full set in one go)

  HTH,
   Thomas