Hi Stefan, > > This patch series enables QEMU's system emulator to run in a browser using > > Emscripten. > > It includes implementations and workarounds to address browser environment > > limitations, as shown in the following. > > I think it would be great to merge this even if there are limitations > once code review comments have been addressed. Developing WebAssembly > support in-tree is likely to allow this effort to develop further than > if done in personal repos (and with significant efforts required to > rebase the code periodically). > > > # New TCG Backend for Browsers > > > > A new TCG backend translates IR instructions into Wasm instructions and runs > > them using the browser's WebAssembly APIs (WebAssembly.Module and > > WebAssembly.instantiate). To minimize compilation overhead and avoid hitting > > the browser's limitation of the number of instances, this backend integrates > > a forked TCI. TBs run on TCI by default, with frequently executed TBs > > compiled into WebAssembly. > > > > # Workaround for Running 64-bit Guests > > > > The current implementation uses Wasm's 32-bit memory model, even though Wasm > > supports 64-bit variables and instructions. This patch explores implementing > > TCG 64-bit instructions while leveraging SoftMMU for address translation. To > > enable 64-bit guest support in Wasm today, it was necessary to partially > > revert recent changes that removed support for different pointer widths > > between the host and guest (e.g., commits > > a70af12addd9060fdf8f3dbd42b42e3072c3914f and > > bf455ec50b6fea15b4d2493059365bf94c706273) when compiling with > > Emscripten. While this serves as a temporary workaround, a long-term > > solution could involve adopting Wasm's 64-bit memory model once it gains > > broader support, as it is currently not widely adopted (e.g., unsupported by > > Safari and libffi). Feedback and suggestions on this approach are welcome. > > > > # Emscripten-Based Coroutine Backend > > > > Emscripten does not support couroutine methods currently used by QEMU but > > provides a coroutine implementation called "fiber". This patch series > > introduces a coroutine backend using fiber. However, fiber does not support > > submitting coroutines to other threads. So this patch series modifies > > hw/9pfs/coth.h to disable this behavior when compiled with Emscripten. > > QEMU's block job coroutines also rely on switching between threads. See > how job_co_entry() schedules job_exit(). It's not very likely that users > will run jobs in a WebAssembly environment, so maybe this is more of a > theoretical problem for the time being.
Thank you for the feedback. I'll investigate the block job coroutines further. As you pointed out, I agree that users aren't likely to run block jobs in the WebAssembly environment. > If I understand correctly the QEMU project is only build the statically > linked wasm binary in the CI system and not distributing it (e.g. making > it available for download)? I'm asking because if the QEMU project wants > to distribute the wasm binary it may be necessary to put together a > combined software license to meet the license requirements of glib and > other dependencies that are statically linked. Yes, it doesn't distribute the statically linked wasm binary.
