To enable guest OS to run SDL applications using bidirectional queues,
the VMM or system emulator must access the guest OS's virtual memory,
as the queues are defined there. This requires MMU translation.

Export rv->io.mem_trans() to perform gVA2gPA translation. Unifying
MMU translation logic by using rv->io.mem_trans(), eliminating redundant
flows: mmu_walk -> check_pg_fault -> check_signal -> get_ppn_and_offset.
Also, this interface allowing src/syscall_sdl.c to handle virtual
memory.

TODO: dTLB can be introduced in rv->io.mem_trans() to cache the gVA2gPA
translation.

See: sysprog21#310, sysprog21#510

To enable guest OS to run SDL applications using bidirectional queues,
the VMM or system emulator must access the guest OS's virtual memory,
as the queues are defined there. This requires MMU translation.

Export rv->io.mem_trans() to perform gVA2gPA translation. Unifying
MMU translation logic by using rv->io.mem_trans(), eliminating redundant
flows: mmu_walk -> check_pg_fault -> check_signal -> get_ppn_and_offset.
Also, this interface allowing src/syscall_sdl.c to handle virtual
memory.

TODO: dTLB can be introduced in rv->io.mem_trans() to cache the gVA2gPA
translation.

See: sysprog21#310, sysprog21#510

To enable guest OS to run SDL applications using bidirectional queues,
the VMM or system emulator must access the guest OS's virtual memory,
as the queues are defined there. This requires MMU translation. In
addition, the queues event data size likely larger than a word (maybe a
page), thus the existing rv->io.mem_{read,write}_w do not sufficient for
such memory manipulation.

Export rv->io.mem_translate() to perform gVA2gPA translation. Unifying
MMU translation logic by using rv->io.mem_translate(), eliminating
redundant flows:
mmu_walk -> check_pg_fault -> check_signal -> get_ppn_and_offset.
Also, this interface allowing src/syscall_sdl.c to handle virtual
memory by first translating the gVA2gPA, followed by memory_{read/write}
the chunk of data at once.

TODO: dTLB can be introduced in rv->io.mem_trans() to cache the gVA2gPA
translation.

See: sysprog21#310, sysprog21#510

During the enhancement of guestOS to run SDL-based applications like
Doom, the Doom artifacts (DOOM1.wad) occupy 4.0MiB, and the default
rootfs.cpio also uses 4.0MiB, totaling 8MiB. When additional
applications are added to rootfs.cpio, the hard-coded 8MiB limit for
rootfs.cpio in map_file becomes insufficient. This commit refines the
hard-coded memory layout variables and makes them configurable during
the build.

The user can now define MEM_SIZE, DTB_SIZE, and INITRD_SIZE in MiB,
while other memory offsets are calculated dynamically based on these
values.

Related: sysprog21#510

During the enhancement of guestOS to run SDL-based applications like
Doom, the Doom artifacts (DOOM1.wad) occupy 4.0MiB, and the default
rootfs.cpio also uses 4.0MiB, totaling 8MiB. When additional
applications are added to rootfs.cpio, the hard-coded 8MiB limit for
rootfs.cpio in map_file becomes insufficient. This commit refines the
hard-coded memory layout variables and makes them configurable during
the build.

The user can now define MEM_SIZE, DTB_SIZE, and INITRD_SIZE in MiB,
while other memory offsets are calculated dynamically based on these
values.

Related: sysprog21#510

During the enhancement of guestOS to run SDL-based applications like
Doom, the Doom artifacts (DOOM1.wad) occupy 4.0MiB, and the default
rootfs.cpio also uses 4.0MiB, totaling 8MiB. When additional
applications are added to rootfs.cpio, the hard-coded 8MiB limit for
rootfs.cpio in map_file becomes insufficient. This commit refines the
hard-coded memory layout variables and makes them configurable during
the build.

The user can now define MEM_SIZE, DTB_SIZE, and INITRD_SIZE in MiB,
while other memory offsets are calculated dynamically based on these
values.

Related: sysprog21#510

During the enhancement of guestOS to run SDL-based applications like
Doom, the Doom artifacts (DOOM1.wad) occupy 4.0MiB, and the default
rootfs.cpio also uses 4.0MiB, totaling 8MiB. When additional
applications are added to rootfs.cpio, the hard-coded 8MiB limit for
rootfs.cpio in map_file becomes insufficient. This commit refines the
hard-coded memory layout variables and makes them configurable during
the build.

The user can now define MEM_SIZE, DTB_SIZE, and INITRD_SIZE in MiB,
while other memory offsets are calculated dynamically based on these
values.

Related: sysprog21#510

During the enhancement of guestOS to run SDL-based applications like
Doom, the Doom artifacts (DOOM1.wad) occupy 4.0MiB, and the default
rootfs.cpio also uses 4.0MiB, totaling 8MiB. When additional
applications are added to rootfs.cpio, the hard-coded 8MiB limit for
rootfs.cpio in map_file becomes insufficient. This commit refines the
hard-coded memory layout variables and makes them configurable during
the build.

The user can now define MEM_SIZE, DTB_SIZE, and INITRD_SIZE in MiB,
while other memory offsets are calculated dynamically based on these
values.

Related: sysprog21#510

During the enhancement of guestOS to run SDL-based applications like
Doom, the Doom artifacts (DOOM1.wad) occupy 4.0MiB, and the default
rootfs.cpio also uses 4.0MiB, totaling 8MiB. When additional
applications are added to rootfs.cpio, the hard-coded 8MiB limit for
rootfs.cpio in map_file becomes insufficient. This commit refines the
hard-coded memory layout variables and makes them configurable during
the build.

The user can now define MEM_SIZE, DTB_SIZE, and INITRD_SIZE in MiB,
while other memory offsets are calculated dynamically based on these
values.

Related: sysprog21#510

During the enhancement of guestOS to run SDL-based applications like
Doom, the Doom artifacts (DOOM1.wad) occupy 4.0MiB, and the default
rootfs.cpio also uses 4.0MiB, totaling 8MiB. When additional
applications are added to rootfs.cpio, the hard-coded 8MiB limit for
rootfs.cpio in map_file becomes insufficient. This commit refines the
hard-coded memory layout variables and makes them configurable during
the build.

The user can now define MEM_SIZE, DTB_SIZE, and INITRD_SIZE in MiB,
while other memory offsets are calculated dynamically based on these
values.

Related: sysprog21#510

To enable guest OS to run SDL applications using bidirectional queues,
the VMM or system emulator must access the guest OS's virtual memory,
as the queues are defined there. This requires MMU translation. In
addition, the queues event data size likely larger than a word (maybe a
page), thus the existing rv->io.mem_{read,write}_w do not sufficient for
such memory manipulation.

Export rv->io.mem_translate() to perform gVA2gPA translation. Unifying
MMU translation logic by using rv->io.mem_translate(), eliminating
redundant flows:
mmu_walk -> check_pg_fault -> check_signal -> get_ppn_and_offset.
Also, this interface allowing src/syscall_sdl.c to handle virtual
memory by first translating the gVA2gPA, followed by memory_{read/write}
the chunk of data at once.

TODO: dTLB can be introduced in rv->io.mem_trans() to cache the gVA2gPA
translation.

See: sysprog21#310, sysprog21#510

During the enhancement of guestOS to run SDL-based applications like
Doom, the Doom artifacts (DOOM1.wad) occupy 4.0MiB, and the default
rootfs.cpio also uses 4.0MiB, totaling 8MiB. When additional
applications are added to rootfs.cpio, the hard-coded 8MiB limit for
rootfs.cpio in map_file becomes insufficient. This commit refines the
hard-coded memory layout variables and makes them configurable during
the build.

The user can now define MEM_SIZE, DTB_SIZE, and INITRD_SIZE in MiB,
while other memory offsets are calculated dynamically based on these
values.

Related: sysprog21#510

To enable guest OS to run SDL applications using bidirectional queues,
the VMM or system emulator must access the guest OS's virtual memory,
as the queues are defined there. This requires MMU translation. In
addition, the queues event data size likely larger than a word (maybe a
page), thus the existing rv->io.mem_{read,write}_w do not sufficient for
such memory manipulation.

Export rv->io.mem_translate() to perform gVA2gPA translation. Unifying
MMU translation logic by using rv->io.mem_translate(), eliminating
redundant flows:
mmu_walk -> check_pg_fault -> check_signal -> get_ppn_and_offset.
Also, this interface allowing src/syscall_sdl.c to handle virtual
memory by first translating the gVA2gPA, followed by memory_{read/write}
the chunk of data at once.

TODO: dTLB can be introduced in rv->io.mem_trans() to cache the gVA2gPA
translation.

See: sysprog21#310, sysprog21#510

During the enhancement of guestOS to run SDL-based applications like
Doom, the Doom artifacts (DOOM1.wad) occupy 4.0MiB, and the default
rootfs.cpio also uses 4.0MiB, totaling 8MiB. When additional
applications are added to rootfs.cpio, the hard-coded 8MiB limit for
rootfs.cpio in map_file becomes insufficient. This commit refines the
hard-coded memory layout variables and makes them configurable during
the build.

The user can now define MEM_SIZE, DTB_SIZE, and INITRD_SIZE in MiB,
while other memory offsets are calculated dynamically based on these
values.

Related: sysprog21#510

To enable guest OS to run SDL applications using bidirectional queues,
the VMM or system emulator must access the guest OS's virtual memory,
as the queues are defined there. This requires MMU translation. In
addition, the queues event data size likely larger than a word (maybe a
page), thus the existing rv->io.mem_{read,write}_w do not sufficient for
such memory manipulation.

Export rv->io.mem_translate() to perform gVA2gPA translation. Unifying
MMU translation logic by using rv->io.mem_translate(), eliminating
redundant flows:
mmu_walk -> check_pg_fault -> check_signal -> get_ppn_and_offset.
Also, this interface allowing src/syscall_sdl.c to handle virtual
memory by first translating the gVA2gPA, followed by memory_{read/write}
the chunk of data at once.

TODO: dTLB can be introduced in rv->io.mem_trans() to cache the gVA2gPA
translation.

See: sysprog21#310, sysprog21#510

During the enhancement of guestOS to run SDL-based applications like
Doom, the Doom artifacts (DOOM1.wad) occupy 4.0MiB, and the default
rootfs.cpio also uses 4.0MiB, totaling 8MiB. When additional
applications are added to rootfs.cpio, the hard-coded 8MiB limit for
rootfs.cpio in map_file becomes insufficient. This commit refines the
hard-coded memory layout variables and makes them configurable during
the build.

The user can now define MEM_SIZE, DTB_SIZE, and INITRD_SIZE in MiB,
while other memory offsets are calculated dynamically based on these
values.

Related: sysprog21#510

To trap the guest OS SDL applications, virtual memory translation should
be handled when accessing the bidirectional event queues in
syscall_sdl.c. Additionally, when using the guest OS, the SDL
application might be launched and terminated multiple times. To enhance
the user experience, it is heuristic to properly handle three main types
of exits:
1, SDL application built-in exit: The source code of the SDL application
   should be modified to call the syscall_exit(syscall number: 93)
   somewhere when executing cleanup routine before exit().
2. Ctrl-c (SIGINT) exit: Detect the ctrl-c keycode.
3. SDL window Quit event: The source code of the SDL application
   should be modified to call the syscall_exit(syscall number: 93) when
   receiving SDL window Quit event.

The main reason for handling these three types of exits is that
SDL2_Mixer may malfunction if not properly initialized and destroyed, as
it runs on the host side not on the guest side. Additionally, when
terminating an SDL application in the guest OS, the previous SDL window
should be closed.

Moreover, the default audio backend of SDL2_Mixer(downloadable from brew
or Linux distro pkg managers), FluidSynth, occasionally generates the
warning: "fluidsynth: warning: Ringbuffer full, try
increasing synth.polyphony!" This issue causes the audio to hang,
leading to an unstable playback experience. Thus, dropping FluidSynth in
favor of the Timidity backend, which provides a stable audio playback
experience.

Known issue: Calling SDL_DestroyWindow() on macOS does not close the
previous SDL window.

Close: sysprog21#510

To trap the guest OS SDL applications, virtual memory translation should
be handled when accessing the bidirectional event queues in
syscall_sdl.c. Additionally, when using the guest OS, the SDL
application might be launched and terminated multiple times. To enhance
the user experience, it is heuristic to properly handle three main types
of exits:
1, SDL application built-in exit: The source code of the SDL application
   should be modified to call the syscall_exit(syscall number: 93)
   somewhere when executing cleanup routine before exit().
2. Ctrl-c (SIGINT) exit: Detect the ctrl-c keycode.
3. SDL window Quit event: The source code of the SDL application
   should be modified to call the syscall_exit(syscall number: 93) when
   receiving SDL window Quit event.

The main reason for handling these three types of exits is that
SDL2_Mixer may malfunction if not properly initialized and destroyed, as
it runs on the host side not on the guest side. Additionally, when
terminating an SDL application in the guest OS, the previous SDL window
should be closed.

Moreover, the default audio backend of SDL2_Mixer(downloadable from brew
or Linux distro pkg managers), FluidSynth, occasionally generates the
warning: "fluidsynth: warning: Ringbuffer full, try
increasing synth.polyphony!" This issue causes the audio to hang,
leading to an unstable playback experience. Thus, dropping FluidSynth in
favor of the Timidity backend, which provides a stable audio playback
experience.

Known issue: Calling SDL_DestroyWindow() on macOS does not close the
previous SDL window.

Close: sysprog21#510

To trap the guest OS SDL applications, virtual memory translation should
be handled when accessing the bidirectional event queues in
syscall_sdl.c. Additionally, when using the guest OS, the SDL
application might be launched and terminated multiple times. To enhance
the user experience, it is heuristic to properly handle three main types
of exits:
1, SDL application built-in exit: The source code of the SDL application
   should be modified to call the syscall_exit(syscall number: 93)
   somewhere when executing cleanup routine before exit().
2. Ctrl-c (SIGINT) exit: Detect the ctrl-c keycode.
3. SDL window Quit event: The source code of the SDL application
   should be modified to call the syscall_exit(syscall number: 93) when
   receiving SDL window Quit event.

The main reason for handling these three types of exits is that
SDL2_Mixer may malfunction if not properly initialized and destroyed, as
it runs on the host side not on the guest side. Additionally, when
terminating an SDL application in the guest OS, the previous SDL window
should be closed.

Moreover, the default audio backend of SDL2_Mixer(downloadable from brew
or Linux distro pkg managers), FluidSynth, occasionally generates the
warning: "fluidsynth: warning: Ringbuffer full, try
increasing synth.polyphony!" This issue causes the audio to hang,
leading to an unstable playback experience. Thus, dropping FluidSynth in
favor of the Timidity backend, which provides a stable audio playback
experience.

Known issue: Calling SDL_DestroyWindow() on macOS does not close the
previous SDL window.

Close: sysprog21#510

To trap the guest OS SDL applications, virtual memory translation should
be handled when accessing the bidirectional event queues in
syscall_sdl.c. Additionally, when using the guest OS, the SDL
application might be launched and terminated multiple times. To enhance
the user experience, it is heuristic to properly handle three main types
of exits:
1, SDL application built-in exit: The source code of the SDL application
   should be modified to call the syscall_exit(syscall number: 93)
   somewhere when executing cleanup routine before exit().
2. Ctrl-c (SIGINT) exit: Detect the ctrl-c keycode.
3. SDL window Quit event: The source code of the SDL application
   should be modified to call the syscall_exit(syscall number: 93) when
   receiving SDL window Quit event.

The main reason for handling these three types of exits is that
SDL2_Mixer may malfunction if not properly initialized and destroyed, as
it runs on the host side not on the guest side. Additionally, when
terminating an SDL application in the guest OS, the previous SDL window
should be closed.

Moreover, the default audio backend of SDL2_Mixer(downloadable from brew
or Linux distro pkg managers), FluidSynth, occasionally generates the
warning: "fluidsynth: warning: Ringbuffer full, try
increasing synth.polyphony!" This issue causes the audio to hang,
leading to an unstable playback experience. Thus, dropping FluidSynth in
favor of the Timidity backend, which provides a stable audio playback
experience.

Known issue: Calling SDL_DestroyWindow() on macOS does not close the
previous SDL window.

Close: sysprog21#510

To trap the guest OS SDL applications, virtual memory translation should
be handled when accessing the bidirectional event queues in
syscall_sdl.c. Additionally, when using the guest OS, the SDL
application might be launched and terminated multiple times. To enhance
the user experience, it is heuristic to properly handle three main types
of exits:
1, SDL application built-in exit: The source code of the SDL application
   should be modified to call the syscall_exit(syscall number: 93)
   somewhere when executing cleanup routine before exit().
2. Ctrl-c (SIGINT) exit: Detect the ctrl-c keycode.
3. SDL window Quit event: The source code of the SDL application
   should be modified to call the syscall_exit(syscall number: 93) when
   receiving SDL window Quit event.

The main reason for handling these three types of exits is that
SDL2_Mixer may malfunction if not properly initialized and destroyed, as
it runs on the host side not on the guest side. Additionally, when
terminating an SDL application in the guest OS, the previous SDL window
should be closed.

Moreover, the default audio backend of SDL2_Mixer(downloadable from brew
or Linux distro pkg managers), FluidSynth, occasionally generates the
warning: "fluidsynth: warning: Ringbuffer full, try
increasing synth.polyphony!" This issue causes the audio to hang,
leading to an unstable playback experience. Thus, dropping FluidSynth in
favor of the Timidity backend, which provides a stable audio playback
experience.

Known issue: Calling SDL_DestroyWindow() on macOS does not close the
previous SDL window.

Close: sysprog21#510

To enable guest OS to run SDL applications using bidirectional queues,
the VMM or system emulator must access the guest OS's virtual memory,
as the queues are defined there. This requires MMU translation. In
addition, the queues event data size likely larger than a word (maybe a
page), thus the existing rv->io.mem_{read,write}_w do not sufficient for
such memory manipulation.

Export rv->io.mem_translate() to perform gVA2gPA translation. Unifying
MMU translation logic by using rv->io.mem_translate(), eliminating
redundant flows:
mmu_walk -> check_pg_fault -> check_signal -> get_ppn_and_offset.
Also, this interface allowing src/syscall_sdl.c to handle virtual
memory by first translating the gVA2gPA, followed by memory_{read/write}
the chunk of data at once.

TODO: dTLB can be introduced in rv->io.mem_trans() to cache the gVA2gPA
translation.

See: sysprog21#310, sysprog21#510

During the enhancement of guestOS to run SDL-based applications like
Doom, the Doom artifacts (DOOM1.wad) occupy 4.0MiB, and the default
rootfs.cpio also uses 4.0MiB, totaling 8MiB. When additional
applications are added to rootfs.cpio, the hard-coded 8MiB limit for
rootfs.cpio in map_file becomes insufficient. This commit refines the
hard-coded memory layout variables and makes them configurable during
the build.

The user can now define MEM_SIZE, DTB_SIZE, and INITRD_SIZE in MiB,
while other memory offsets are calculated dynamically based on these
values.

Related: sysprog21#510

To trap the guest OS SDL applications, virtual memory translation should
be handled when accessing the bidirectional event queues in
syscall_sdl.c. Additionally, when using the guest OS, the SDL
application might be launched and terminated multiple times. To enhance
the user experience, it is heuristic to properly handle three main types
of exits:
1, SDL application built-in exit: The source code of the SDL application
   should be modified to call the syscall_exit(syscall number: 93)
   somewhere when executing cleanup routine before exit().
2. Ctrl-c (SIGINT) exit: Detect the ctrl-c keycode.
3. SDL window Quit event: The source code of the SDL application
   should be modified to call the syscall_exit(syscall number: 93) when
   receiving SDL window Quit event.

The main reason for handling these three types of exits is that
SDL2_Mixer may malfunction if not properly initialized and destroyed, as
it runs on the host side not on the guest side. Additionally, when
terminating an SDL application in the guest OS, the previous SDL window
should be closed.

Moreover, the default audio backend of SDL2_Mixer(downloadable from brew
or Linux distro pkg managers), FluidSynth, occasionally generates the
warning: "fluidsynth: warning: Ringbuffer full, try
increasing synth.polyphony!" This issue causes the audio to hang,
leading to an unstable playback experience. Thus, dropping FluidSynth in
favor of the Timidity backend, which provides a stable audio playback
experience.

Known issue: Calling SDL_DestroyWindow() on macOS does not close the
previous SDL window.

Close: sysprog21#510

To trap the guest OS SDL applications, virtual memory translation should
be handled when accessing the bidirectional event queues in
syscall_sdl.c. Additionally, when using the guest OS, the SDL
application might be launched and terminated multiple times. To enhance
the user experience, it is heuristic to properly handle three main types
of exits:
1, SDL application built-in exit: The source code of the SDL application
   should be modified to call the syscall_exit(syscall number: 93)
   somewhere when executing cleanup routine before exit().
2. Ctrl-c (SIGINT) exit: Detect the ctrl-c keycode.
3. SDL window Quit event: The source code of the SDL application
   should be modified to call the syscall_exit(syscall number: 93) when
   receiving SDL window Quit event.

The main reason for handling these three types of exits is that
SDL2_Mixer may malfunction if not properly initialized and destroyed, as
it runs on the host side not on the guest side. Additionally, when
terminating an SDL application in the guest OS, the previous SDL window
should be closed.

Moreover, the default audio backend of SDL2_Mixer(downloadable from brew
or Linux distro pkg managers), FluidSynth, occasionally generates the
warning: "fluidsynth: warning: Ringbuffer full, try
increasing synth.polyphony!" This issue causes the audio to hang,
leading to an unstable playback experience. Thus, dropping FluidSynth in
favor of the Timidity backend, which provides a stable audio playback
experience.

Known issue: Calling SDL_DestroyWindow() on macOS does not close the
previous SDL window.

Close: sysprog21#510

To trap the guest OS SDL applications, virtual memory translation should
be handled when accessing the bidirectional event queues in
syscall_sdl.c. Additionally, when using the guest OS, the SDL
application might be launched and terminated multiple times. To enhance
the user experience, it is heuristic to properly handle three main types
of exits:
1, SDL application built-in exit: The source code of the SDL application
   should be modified to call the syscall_exit(syscall number: 93)
   somewhere when executing cleanup routine before exit().
2. Ctrl-c (SIGINT) exit: Detect the ctrl-c keycode.
3. SDL window Quit event: The source code of the SDL application
   should be modified to call the syscall_exit(syscall number: 93) when
   receiving SDL window Quit event.

The main reason for handling these three types of exits is that
SDL2_Mixer may malfunction if not properly initialized and destroyed, as
it runs on the host side not on the guest side. Additionally, when
terminating an SDL application in the guest OS, the previous SDL window
should be closed.

Moreover, the default audio backend of SDL2_Mixer(downloadable from brew
or Linux distro pkg managers), FluidSynth, occasionally generates the
warning: "fluidsynth: warning: Ringbuffer full, try
increasing synth.polyphony!" This issue causes the audio to hang,
leading to an unstable playback experience. Thus, dropping FluidSynth in
favor of the Timidity backend, which provides a stable audio playback
experience.

Known issue: Calling SDL_DestroyWindow() on macOS does not close the
previous SDL window.

Close: sysprog21#510

To trap the guest OS SDL applications, virtual memory translation should
be handled when accessing the bidirectional event queues in
syscall_sdl.c. Additionally, when using the guest OS, the SDL
application might be launched and terminated multiple times. To enhance
the user experience, it is heuristic to properly handle three main types
of exits:
1, SDL application built-in exit: The source code of the SDL application
   should be modified to call the syscall_exit(syscall number: 93)
   somewhere when executing cleanup routine before exit().
2. Ctrl-c (SIGINT) exit: Detect the ctrl-c keycode.
3. SDL window Quit event: The source code of the SDL application
   should be modified to call the syscall_exit(syscall number: 93) when
   receiving SDL window Quit event.

The main reason for handling these three types of exits is that
SDL2_Mixer may malfunction if not properly initialized and destroyed, as
it runs on the host side not on the guest side. Additionally, when
terminating an SDL application in the guest OS, the previous SDL window
should be closed.

Moreover, the default audio backend of SDL2_Mixer(downloadable from brew
or Linux distro pkg managers), FluidSynth, occasionally generates the
warning: "fluidsynth: warning: Ringbuffer full, try
increasing synth.polyphony!" This issue causes the audio to hang,
leading to an unstable playback experience. Thus, dropping FluidSynth in
favor of the Timidity backend, which provides a stable audio playback
experience.

Known issue: Calling SDL_DestroyWindow() on macOS does not close the
previous SDL window.

Close: sysprog21#510