HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
qemu
qemu
C2015–2026
qemu / qemu

qemu

Official QEMU mirror. Please see https://www.qemu.org/contribute/ for how to submit changes to QEMU. Pull Requests are disabled. Please only use release tarballs from the QEMU website.

Games & EmulationWeb DevelopmentSystems & Infrastructure
Explore on GitHubRead Hacker News discussions
35Distinct people
47Mentions
1Explicit recommenders
14KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Official QEMU mirror. Please see https://www.qemu.org/contribute/ for how to submit changes to QEMU. Pull Requests are disabled. Please only use release tarballs from the QEMU website.

GitHub

Where it is used

The source check is incomplete. Verified examples will appear here.

What people are saying

Qualcomm | Canada | Full Time | Engineer | Remote(Canada)| QEMU My team is looking to hire a ~entry-level software developer to help us design and extend QEMU support [1] for…

quic_bcain used a recommendation phrase. 7 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year47 dated mentions

Observed mentions: 2015-05-13 15:33:11 UTC to 2026-10-01 23:53:15 UTC.

02468102015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 3 mentions; 2 submissions, 1 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 10 mentions; 0 submissions, 10 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC101
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC312
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC321
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC707
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC202
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC909
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC606
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC10010
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC211
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC303

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
QEMU README QEMU is a generic and open source machine & userspace emulator and virtualizer. QEMU is capable of emulating a complete machine in software without any need for hardware virtualization support. By using dynamic translation, it achieves very good performance. QEMU can also integrate with the Xen and KVM hypervisors to provide emulated hardware while allowing the hypervisor to manage the CPU. With hypervisor support, QEMU can achieve near native performance for CPUs. When QEMU emulates CPUs directly it is capable of running operating systems made for one machine (e.g. an ARMv7 board) on a different machine (e.g. an x86_64 PC board). QEMU is also capable of providing userspace API virtualization for Linux and BSD kernel interfaces. This allows binaries compiled against one architecture ABI (e.g. the Linux PPC64 ABI) to be run on a host using a different architecture ABI (e.g. the Linux x86_64 ABI). This does not involve any hardware emulation, simply CPU and syscall emulation. QEMU aims to fit into a variety of use cases. It can be invoked directly by users wishing to have full control over its behaviour and settings. It also aims to facilitate integration into higher level management layers, by providing a stable command line interface and monitor API. It is commonly invoked indirectly via the libvirt library when using open source applications such as oVirt, OpenStack and virt-manager. QEMU as a whole is released under the GNU General Public License, version 2. For full licensing details, consult the LICENSE file. Documentation Documentation can be found hosted online at https://www.qemu.org/documentation/. The documentation for the current development version that is available at https://www.qemu.org/docs/master/ is generated from the docs/ folder in the source tree, and is built by Sphinx. Building QEMU is multi-platform software intended to be buildable on all modern Linux platforms, OS-X, Win32 (via the Mingw64 toolchain) and a variety of other UNIX targets. The simple steps to build QEMU are: mkdir build cd build ../configure make Additional information can also be found online via the QEMU website: https://wiki.qemu.org/Hosts/Linux https://wiki.qemu.org/Hosts/Mac https://wiki.qemu.org/Hosts/W32 Submitting patches The QEMU source code is maintained under the GIT version control system. git clone https://gitlab.com/qemu-project/qemu.git When submitting patches, one common approach is to use 'git format-patch' and/or 'git send-email' to format & send the mail to the qemu-devel@nongnu.org mailing list. All patches submitted must contain a 'Signed-off-by' line from the author. Patches should follow the guidelines set out in the style section of the Developers Guide. Additional information on submitting patches can be found online via the QEMU website: https://wiki.qemu.org/Contribute/SubmitAPatch https://wiki.qemu.org/Contribute/TrivialPatches The QEMU website is also maintained under source control. git clone https://gitlab.com/qemu-project/qemu-web.git https://www.qemu.org/2017/02/04/the-new-qemu-website-is-up/ A 'git-publish' utility was created to make above process less cumbersome, and is highly recommended for making regular contributions, or even just for sending consecutive patch series revisions. It also requires a working 'git send-email' setup, and by default doesn't automate everything, so you may want to go through the above steps manually for once. For installation instructions, please go to: https://github.com/stefanha/git-publish The workflow with 'git-publish' is: $ git checkout master -b my-feature $ # work on new commits, add your 'Signed-off-by' lines to each $ git publish Your patch series will be sent and tagged as my-feature-v1 if you need to refer back to it in the future. Sending v2: $ git checkout my-feature # same topic branch $ # making changes to the commits (using 'git rebase', for example) $ git publish Your patch series will be sent with 'v2' tag in the subject and the git tip will be tagged as my-feature-v2. Bug reporting The QEMU project uses GitLab issues to track bugs. Bugs found when running code built from QEMU git or upstream released sources should be reported via: https://gitlab.com/qemu-project/qemu/-/issues If using QEMU via an operating system vendor pre-built binary package, it is preferable to report bugs to the vendor's own bug tracker first. If the bug is also known to affect latest upstream code, it can also be reported via GitLab. For additional information on bug reporting consult: https://wiki.qemu.org/Contribute/ReportABug ChangeLog For version history and release notes, please visit https://wiki.qemu.org/ChangeLog/ or look at the git history for more detailed information. Contact The QEMU community can be contacted in a number of ways, with the two main methods being email and IRC: mailto:qemu-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/qemu-devel #qemu on irc.oftc.net Information on additional methods of contacting the community can be found online via the QEMU website: https://wiki.qemu.org/Contribute/StartHere
Read the full README on GitHub

What Hacker News says

47 sources
quic_bcain·Oct 1, 2026Recommendation phrase
Qualcomm | Canada | Full Time | Engineer | Remote(Canada)| QEMU My team is looking to hire a ~entry-level software developer to help us design and extend QEMU support [1] for the Hexagon DSP [2]. We're looking for candidates who have experience coding in C, C++ or Rust* and who aren't afraid of rolling up their sleeves and poring over disassembled code. This particular architecture is a bit more challenging than most, because it's a bit unique. It's a VLIW [3], so it's a great opportunity to learn about an interesting architecture. Millions of Hexagon DSPs are out there, most are found in DragonWing/Snapdragon/DragonFly SoCs for Laptops, Android phones, cars and more! We collaborate a lot with Open Source communities like QEMU, LLVM [4], the Linux kernel [5], and more. I love being able to work on Open Source software at my day job. You
Read the rest
can contact me directly (email addr is in my HN user link). If you don't have experience with QEMU - don't worry! Most of us didn't have any experience with it until recently, too. The rest of the team you'd work with lives mostly in Canada, EU, US. The position is only available to people residing and working in Canada. * Rust experience may serve the role well but we don’t (yet) have any product software in Rust. [1] https://github.com/qemu/qemu/tree/master/target/hexagon [2] https://en.wikipedia.org/wiki/Qualcomm_Hexagon [3] https://en.wikipedia.org/wiki/Very_long_instruction_word [4] https://foundation.llvm.org/sponsors/ [5] https://www.linuxfoundation.org/our-members-are-our-superpow...
In Ask HN: Who is hiring? (October 2026)
m132·May 14, 2026
I experimented with booting Arm macOS 14-26 in QEMU a while back, building on the work of Alexander Graf for macOS 12-13, and reverse-engineered substantial parts of Hypervisor.framework, the in-kernel hypervisor, and a bit of Virtualization.framework. Got newer versions of Sequoia to boot past the log in screen, with GPU acceleration too. Unless there's another method I missed, the internal GPU "pass through" of Virtualization.framework you're thinking of might actually just be paravirualization, at least that's what the name suggests. It's implemented in the public ParavirtualizedGraphics framework [0], albeit for PG on Arm macOS, the relevant interfaces are private [1]. I haven't looked that deep into it per se, but, fixing the bugs around it, I've run into a few clues suggesting that it's just a command stream + shared memory being p
Read the rest
assed around. It also uses its own generic driver on the guest side. Great job, by the way! Love how authors of pieces like this casually come here to comment :) [0] https://developer.apple.com/documentation/paravirtualizedgra... [1] https://github.com/qemu/qemu/blob/edcc429e9e41a8e0e415dcdab6...
In RTX 5090 and M4 MacBook Air: Can It Game?
dijksterhuis·Jun 26, 2025
It's a simpler solution is just to wait until legal situation is clearer. QEMU is (mostly) GPL 2.0 licensed, meaning (most) code contributions need to be GPL 2.0 compatible [0]. Let's say, hypothetically, there's a code contribution added by some patch involving gen AI code which is derived/memorised/copied from non-GPL compatible code [1]. Then, hypothetically, a legal case sets precedent that gen AI FOSS code must re-apply the license of the original derived/memorised/copied code. QEMU maintainers would probably need to roll back all those incompatible code contributions. After some time, those code contributions could have ended up with downstream callers which also need to be rewritten (even in CI code). It might be possible to first say "only CI code which is clearly labelled as 'DO NOT RE-USE: AI' or some such". But the maintainers
Read the rest
would still need to go through and rewrite those parts of the CI code if this hypothetical plays out. Plus it adds extra work to reviews and merge processes etc. it's just less work and less drama for everyone involved to say "no thank you (for now)". ---- caveat: IANAL, and licensing is not my specific expertise (but i would quite like it to be one day) [0]: https://github.com/qemu/qemu/blob/master/LICENSE [1]: e.g. No license / MPL / Apache / Aritistic / Creative Commons https://www.gnu.org/licenses/license-list.html#NonFreeSoftwa...
In Define policy forbidding use of AI code generators
bonzini·Jul 10, 2024
On and off over the last year I have been rewriting QEMU's x86 decoder. It started as a necessary task to incorporate AVX support, but I am now at a point where only a handful of opcodes are left to rewrite, after which it should not be too hard to add APX support. For EVEX my plan is to keep the raw bits until after the opcode has been read (i.e. before immediates and possibly before modrm) and the EVEX class identified. My decoder is mostly based on the tables in the manual, and the code is mostly okay—not too much indentation and phases mostly easy to separate/identify. Because the output is JITted code, it's ok to not be super efficient and keep the code readable; it's not where most of the time is spent. Nevertheless there are several cases in which the manual is wrong or doesn't say the whole story. And the tables haven't been updat
Read the rest
ed for several years (no K register instructions, for example), so going forward there will be more manual work to do. :( The top comment explains a bit what's going on: https://github.com/qemu/qemu/blob/59084feb256c617063e0dbe7e6... (As I said above, there are still a few instructions handled by the old code predating the rewrite, notably BT/BTS/BTR/BTC. I have written the code but not merged it yet).
In Things I learned while writing an x86 emulator (2023)
chubot·Apr 4, 2024
A better solution is just to write a plain ass shell script that tests if various C snippets compile. https://github.com/oilshell/oil/blob/master/configure https://github.com/oilshell/oil/blob/master/build/detect-pwe... Not an unholy mix of m4, shell, and C, all in the same file. --- These are the same style as a the configure scripts that Fabrice Bellard wrote for tcc and QEMU. They are plain ass shell scripts, because he actually understands the code he writes. https://github.com/qemu/qemu/blob/master/configure https://github.com/TinyCC/tinycc/blob/mob/configure OCaml’s configure script is also “normal”. You don’t have to copy and paste thousands of lines of GNU stuff that you don’t understand. (copy of lobste.rs comment)
In Autoconf makes me think we stopped evolving too soon
peter_d_sherman·Feb 18, 2024
Related: "A fast Pascal (Delphi) WebAssembly interpreter": https://github.com/marat1961/wasm "WASM-4": https://github.com/aduros/wasm4 "Curated list of awesome things regarding WebAssembly (wasm) ecosystem": https://github.com/mbasso/awesome-wasm Google Chromium/Chrome V8 (JavaScript Engine) WASM Source Code branch: https://github.com/v8/v8/tree/main/src/wasm Also... it would be nice if there was a WASM software/soft CPU for QEMU, which (if it existed!) would go here: https://github.com/qemu/qemu/tree/master/target
In WASM Instructions
aleclm·Jan 13, 2024
> architectural registers are always updated In tiny code, the guest registers (global TCG variables) are stored in the host's registers until you either call an helper which can access the CPU state or you return (`git grep la_global_sync`). This is the reason why QEMU is not so terribly slow. But after a check, this also happens when you access the guest memory address space! https://github.com/qemu/qemu/blob/master/include/tcg/tcg-opc... (TCG_OPF_SIDE_EFFECTS is what matters) But still, in the end, it's the same problem. What QEMU does, can be done in LLVM too. You could probably be more efficient in LLVM by using the exception handling mechanism (invoke and friends) to only serialize back to memory when there's an actual exception, at the cost of higher register pressure. More or less what we do here: https://rev.ng/downloads/bar-2019
Read the rest
-paper.pdf
In revng translates (i386, x86-64, MIPS, ARM, AArch64, s390x) binaries to LLVM IR

Showing the 15 most recent of 47 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.