Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Trap-and-emulate guestOS SDL-based applications #510

Open
ChinYikMing opened this issue Nov 3, 2024 · 3 comments
Open

Trap-and-emulate guestOS SDL-based applications #510

ChinYikMing opened this issue Nov 3, 2024 · 3 comments
Assignees
@ChinYikMing
Labels
enhancement New feature or request

Comments

@ChinYikMing
Copy link
Collaborator

ChinYikMing commented Nov 3, 2024 •
edited
Loading

Currently, the guest OS primarily uses its own syscall table. To enable it to run SDL-based applications, we may need to trap and emulate the SDL instruction, which would be handled by the rv32emu SDL backend.

Goal: at least able to run Doom, Quake and smolnes.

A simple demo is opening a white SDL screen.
image
@ChinYikMing ChinYikMing self-assigned this Nov 3, 2024
@ChinYikMing
Copy link
Collaborator Author

Any chance to run mado?

@jserv
Copy link
Contributor

jserv commented Nov 3, 2024

Any chance to run mado?

Hopefully, Mado is designed as an advanced yet lean window system for resource-constrained environments, making it suitable for system emulation validation.

@ChinYikMing ChinYikMing added the enhancement New feature or request label Nov 9, 2024
ChinYikMing added a commit to ChinYikMing/rv32emu that referenced this issue Jan 3, 2025
@ChinYikMing
Unify MMU translation APIs
ff5d4d7 
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
@ChinYikMing ChinYikMing mentioned this issue Jan 3, 2025
Merged
ChinYikMing added a commit to ChinYikMing/rv32emu that referenced this issue Jan 3, 2025
@ChinYikMing
Unify MMU translation APIs
88f83c8 
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
ChinYikMing added a commit to ChinYikMing/rv32emu that referenced this issue Jan 4, 2025
@ChinYikMing
Unify MMU translation APIs
dfab12e 
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
@ChinYikMing
Copy link
Collaborator Author

ChinYikMing commented Jan 4, 2025 •
edited
Loading

A quick demo to run Doom in guest OS, showing the possibility and capability of the guest OS to handle display and audio :

doom_run_in_guestOS.mp4

BTW, some technical issues have to be resolved:

  • Quake seems has to be increase the memory pool size by changing the source code. (Doom is not necessary)
  • How to reap music thread after the application exit? If this is not handled, the background music might play forever.
  • Sometime the bidirectional event queues is not responding. (guessing the application getting context switch by the guest OS)
  • Sometime getting double free or malloc corrupting error from the host OS (could be investigated by valgrind or address sanitizer)
  • Destroy the previous SDL window after exiting. If this is not handled, the previous SDL window might be reused by the next application, which could cause issues since not all applications have the same window size.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ChinYikMing ChinYikMing

Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jserv @ChinYikMing