copy
Hardware Task Switching (TSS) not supported — prevents Linux 0.11 from running user processes
Hello, and thank you for creating and maintaining v86 — it's an incredible tool for education and lightweight x86 emulation!
I'm trying to run Linux kernel 0.11 (a historical version that uses hardware task switching via TSS for process scheduling) in v86, and I've encountered a compatibility issue that appears related to task switching emulation.
🔍 Observed Behavior
The kernel boots successfully and reaches the first user-space process (/init/main.c).
It calls fork(), which internally invokes do_fork() → copy_process().
copy_process() completes without error: a new task_struct is allocated, its TSS is initialized (including .eax = 0, .eip pointing to the return address of system_call, etc.), and the task state is set to TASK_RUNNING.
The scheduler (schedule()) is invoked and calls switch_to(child_task), which executes:
ljmp _TSS(child), $0
However, the child process never begins executing user-space code — the init() function (which should run in the child after if (!fork())) is never entered.
The system appears to remain in the parent process or hang, with no further progress from the child.
In contrast, the exact same kernel image boots and correctly runs multi-process user space (including init) in QEMU and Bochs.
🧩 Hypothesis (not confirmed)
Linux 0.11 relies on x86 hardware task switching: when ljmp targets a TSS descriptor, the CPU is expected to automatically load the new task’s register state (including EAX=0 for the child) from the TSS and resume execution.
The observed behavior suggests that this hardware task switch may not be fully emulated in v86 — either the TSS is not loaded, or the CPU state restoration does not occur, preventing the child task from resuming correctly.
However, I cannot directly confirm the register state of the child task after switch_to, as I lack visibility into the post-switch context within v86.
💡 Request
Would it be possible to:
- Clarify whether hardware task switching (TSS-based task switches via ljmp/call) is currently supported in v86?
- If not, consider whether basic support could be added to improve compatibility with educational/historical operating systems like Linux 0.11?
I understand this is a legacy x86 feature rarely used in modern software, but it is essential for running early versions of Linux unmodified.
❤️ Thank You
Thank you again for your outstanding work on v86! It has been immensely helpful for learning low-level OS concepts.
Note: This issue was drafted with the assistance of an AI language model, as I’m not fully confident in expressing technical details in English. I’ve made every effort to ensure the description accurately reflects my observations and environment. I hope this is understandable, and I’d be happy to provide further clarification if needed.
Please don't post LLM generated issues. I will leave this one open as it's (probably) valid, but in general it creates an imbalance between reporters (who don't have to put any effort in) and maintainers, who spend significant time triaging issues.
I'm very sorry. Although the content was generated by AI, I spent a lot of time debugging and locating the problem. I think my foreign language proficiency is limited. My native language is Chinese, so I used AI to assist in describing the problem. I also made great efforts to revise it many times. I have tried to search for issues related to TSS. However, it seems that no effective solution has been found. I am already clear about the cause of the problem. It seems that Linux 0.11 relies on hardware task switching, and the v86 project does not seem to support it, as I can run it normally in qemu. In v86, the kernel did not report any errors, but it just couldn't schedule newly created processes