ハクソク

世界を動かす技術を、日本語で。

QEMU 10.1.0

271日前原文(wiki.qemu.org)

概要

  • QEMU 10.1 の主な新機能、非互換変更、削除機能のまとめ
  • 各アーキテクチャ （Arm, RISC-V, x86など）の新規・非推奨機能
  • デバイスエミュレーション、ネットワーク、GUI の主要な改善点
  • ビルド要件、対応プラットフォーム、既知の問題点
  • ドキュメントやサポート体制 の最新情報

QEMU 10.1 リリース概要

  • 削除機能 ・非互換変更の詳細は「Removed features」ページ参照
  • 新たに非推奨となった機能・オプション はユーザーガイド「Deprecated Features」章参照
  • サポート終了 ：Debian bullseye
  • ビルド要件 ：Ninja 1.9必須、Rust 1.77（実験的）、Meson 1.8.1（Rust有効時）

各アーキテクチャの主な変更点

  • Arm

    • 新CPUアーキテクチャ機能： FEAT_SME2, FEAT_SME2p1, FEAT_SME_B16B16 など
    • highbank/midway ボードモデルの非推奨、新規ボード max78000fthr 追加
    • virt ボードでCXLサポート、KVMネスト仮想化・ACPI PCIホットプラグ対応
    • AST2700 EVB マシンのFWサポート、新SoC/ボードモデル追加

  • RISC-V

    • tail擬似命令 サポート、ベクタ命令のコーナーケース修正
    • Ziccif （アトミック命令フェッチ）サポート、PMPリージョン拡張
    • Kunminghu CPU/プラットフォーム 追加、ACPIテーブル更新

  • x86

    • TDXサポート （Linux 6.16以上必須）、IGVMファイルからの仮想マシン起動
    • SEV-SNP/IGDパススルー 改善、VFIO関連機能強化

  • その他アーキテクチャ

    • LoongArch ：カーネルirqchipサポート、エンディアン修正
    • Microblaze ：エンディアン切替プロパティ追加、big-endianバイナリ削除
    • MIPS ：Windows NT起動時BSOD修正
    • s390x ：QOM経由で制御プログラム識別データ取得サポート
    • SPARC, Tricore, HPPA, AVR, Hexagon など：主にバグ修正

デバイスエミュレーション・ネットワーク

  • VFIO

    • CoCo guest-memfd バックエンド初期サポート
    • vfio-userクライアントデバイス 追加、VFIOマイグレーション強化
    • TDX/SNP仮想マシン でのVFIOサポート

  • virtio

    • virtio-gpu ：EDID名注入サポート
    • virtiofs/9pfs ：ファイルディスクリプタ回収・use-after-unlinkの修正

  • ネットワーク

    • NBD over Unixソケット でバッファ拡張（MacOSは即有効、Linuxはsysctl設定要）

  • ブロックデバイス

    • blockdev-mirror ：ゼロブロック処理の最適化、target-is-zeroフラグ追加
    • blockdev-backup ：on-cbw-errorオプション追加

GUI・I/O・プラグイン

  • GUI

    • spice/dbus ：multi-plane dmabufサポート
    • gtk ：スケール・アスペクト比設定追加
    • vnc ：エンディアン違い時のエンコード修正、移行後の表示停止問題修正

  • TCGプラグイン

    • ipsプラグイン ：スケーリング・命令数設定対応
    • 新テストプラグイン 「patcher」追加

  • GDBStub

    • qGDBServerVersion 対応

ビルド・依存関係・CI

  • Rust 1.77必須 （Debian bookworm, Ubuntu 22.04/24.04で利用可、mips64elはDebian trixie以降）
  • Meson 1.8.1 必要（Rust有効時）
  • Ninja 1.9 必須
  • WASMビルド （Emscripten経由）実験的サポート

既知の問題・注意点

  • PowerNV 未有効時、ppc64-softmmuターゲットでリンカエラー発生
    • 対策：KconfigでPOWERNV有効化
  • 詳細は公式マイルストーン・ディスカッション参照
    • https://gitlab.com/qemu-project/qemu/-/milestones/16
    • https://lore.kernel.org/qemu-devel/46991b45-3a03-4e66-a28d-f0178b8780fe@linux.ibm.com/T/#t

ドキュメント・サポート

  • プロセス文書 にb4例追加
  • edk2サブモジュール 全てファームウェアtarballに同梱
  • Rustサポート は実験的（開発用途のみ推奨）
  • Debian bookworm は引き続きサポート対象（Rustは制限あり）

その他

  • ユーザーモードエミュレーション ：制限事項のドキュメント更新
  • Guest agent ：Windows向けguest-get-loadコマンド実装、VSS関連改善
  • Migration ：RDMAでIPv6サポート開始、マルチFDとpostcopyの併用初期サポート
  • テスト・CI ：各種依存性の更新と最適化

このリリースノートは、 QEMU 10.1 の主要な変更点と注意点を簡潔にまとめたものです。詳細は公式ドキュメントおよび各種リンクを参照してください。

Hackerたちの意見

彼らのウェブサイト、壊れてるみたい？

「データベースにアクセスできません」

└

WFM

QEMUは本当に素晴らしいソフトウェアだよ。別のアーキテクチャをエミュレートする必要がほとんどない人から見ればね。とにかく「そのまま動く」し、ほぼ全てのものと素晴らしい統合がされてる。時々、魔法みたいに感じることもあるけど、コマンドラインのUXがちょっと変なところもあるんだよね。でも、KVMとの連携がどうなってるのか、ずっと気になってた。KVMはネイティブコードをCPUに渡すための仮想化アクセラレーターだって知ってるけど、QEMU/KVMが今やインターネットを動かしてる感じがする。現代のクラウドのほとんどはQEMUとKVMをハイパーバイザーとして使ってるよね？でも、どう動いてるのか、まだまだ分からないことが多い気がする。それに、これがエミュレーションから大量のリソースを奪ってるのか、それとも助けになってるのかも気になる。現代のインターネットが主にQEMUで動いてるって言うのは、かなり控えめな表現かもしれないね。

└

すべてがqemuを使ってるわけじゃないよ。一部は使ってるけど、もっと多くはKVMを使ってる。例としては、https://firecracker-microvm.github.io/があるね。

└

そうそう、KVMが実際にどう動いてるのかも気になってた。これが役に立ったよ。 https://www.kernel.org/doc/ols/2007/ols2007v1-pages-225-230.... http://www.haifux.org/lectures/312/High-Level%20Introduction... https://zserge.com/posts/kvm/

└

リソース的には「奪う」ようなことは特にないよ。KVMや仮想化のユースケースに関心がある人や企業はその部分に取り組んでるし、エミュレーションに関心がある人や企業はそっちをやってる。もしQEMUが仮想化をサポートしてなかったら、今QEMUの仮想化に取り組んでる人たちがエミュレーションサポートにシフトするわけじゃないし、彼らは別のプロジェクトに取り組んで自分たちのVM目標を達成しようとするだろうね。

└

KVMは基本的に3つのコンポーネントから成り立ってる。

  • ゲストが物理メモリだと思っているホストユーザープロセスの一部をマッピングするための第二レベルページテーブルの抽象化。
  • そのページテーブルを使うコンテキストにジャンプするための抽象化で、ハードウェアが通常処理するはずのものをハイパーバイザーが手動で処理したい場合にトラップバックする。
  • トラップの種類が一般的な場合、カーネル空間でそれらのトラップを処理するためのメカニズムの集合。これにより、ホストユーザープロセスに戻るためのコンテキストスイッチを避けられる。トラップ自体がパフォーマンスグラフに現れるほど頻繁に発生する場合や、抽象化が比較的一般的な場合（割り込みコントローラーやタイマーを考えてみて）に使われる。何か他に質問があれば教えてね。
└

クラウドを支えるqemu/kvmはすごいけど、それだけじゃなくて他のところでも大きな違いを生んでるよ。新しいOSの開発なんかがその一例。基本的にみんな最初はqemuの仮想ハードウェアをターゲットにするから、実際のハードウェアで動かすよりも開発がずっと早く進むし、ケーブルなしで簡単にデバッグ出力もできるんだ。

└

Xenもまだまだ大量に使われてるよ。

└

たまにしか使わないなら、素晴らしいQuickEMUを強くおすすめするよ。[0] どんなVMもquickget ubuntu 24.04とquickemu --vm ubuntu-24.04.confで簡単に立ち上げられるから。confファイルは読みやすいyaml形式で、コア数やRAM、ディスクも簡単に増やせるよ。quickgetを実行すれば、ダウンロードできるOSのリストが表示されるよ。[0] https://github.com/quickemu-project/quickemu

└

ずっとKVMの仕組みについて気になってたんだ。他の人たちがもっと詳しい説明をしてくれたけど、できるだけシンプルに説明してみるね。普通のQEMUにはTCGっていうCPUエミュレーションレイヤーがあるんだ。マシンは基本的にメモリ（RAMとMMIOデバイス）とCPU（CPUレジスタと状態）から成り立ってる。QEMUがマシンをセットアップして実行の準備ができると、TCGに「このメモリとこの初期CPUレジスタの状態で、命令を実行し始めて」って呼びかけるんだ。KVMを使ったQEMUの場合は、TCGのエミュレーションレイヤーがKVMに置き換わって、KVMに命令を実行するように頼むんだ。それだけ。KVMは、呼び出し元がゲストメモリと初期CPUレジスタの状態を指定できるAPIを提供していて、そのメモリでCPUを実行するための呼び出しをするんだ。さらに進むと、KVMが使うハードウェア仮想化機能は、そのメモリを第二レベルの変換でマッピングする能力があって、KVMがゲストに期待される場所でそれを提示できるようにし、ゲストがアクセスしてはいけないメモリにアクセスするのを防ぐことができるんだ。ハードウェアはまた、CPUを通常のレジスタセットで動かすモードで実行する能力も持っていて（これがQEMUが求めるもの）、ゲストには利用できない追加のハイパーバイザー制御レジスタを維持しているんだ。これによって、ゲストがCPUを完全に制御することができないようにしてる（例えば、ゲストOSが通常のMSRや似たようなビットで「割り込みを無効にする」ことができるけど、それはゲストが割り込みを受け取るのを防ぐだけで、ハイパーバイザーが指示する割り込みは無効にしないから、ハイパーバイザーは常にハイパーバイザー-IPIやハイパーバイザータイマー割り込みでCPUの制御を取り戻せるんだ）。さらに言うと、普通のQEMUモードで実行しているときは、デバイスはメモリアドレス空間にMMIO範囲を登録することでエミュレートされていて、エミュレートされたロードやストアにはこれらの領域を検出するコードがあって、単純なロードやストアを実行する代わりに、デバイスモデルコードに呼び出すんだ。KVMを接続すると、これらのエミュレートされたデバイスも使えるんだ。これらは第二レベルのページテーブルを使って「無効」なマッピングをMMIO範囲に置くことでモデル化されてる。これによって、CPUがそれにアクセスしようとするとページフォルトが発生して、KVMはこれを見て、QEMUが登録したメモリのテーブルを調べて、QEMUが処理したいアドレスだと判断するから、KVM_RUNシステムコールから戻るときにMMIOの読み書きを処理する必要があるという結果コードを返すんだ。QEMUはその後、エミュレートされたデバイスモデルにこれを指示するんだ。そしてQEMUがそのデバイスエミュレーションを実行した後、KVMに戻ってCPUの実行を続けるんだ。全体的にかなり賢い仕組みだよ。本当に驚くべきことは、これらの基本的な概念のほとんどが50年以上前に開発されたり発見されたりしたってことだね。

俺と俺の開発チームの生活を無限に良くしてくれる素晴らしいソフトウェアだよ。QEMUの開発者たちに大感謝 :)

└

QEMUに直接寄付する方法が見つからなかった。唯一見つけたのは https://sfconservancy.org/donate/ だね。

Emscriptenを使ってWASMにコンパイルするための実験的サポートがあるんだって。すごいね。これでいろんなCPUアーキテクチャ向けのオンライン「プレイグラウンド」が解放されるし、他にも面白い使い方ができそう。以前から可能だったかもしれないけど、こうやってプロジェクトに直接機能として追加されるのは嬉しいね。

macOSやiOSを使ってるなら、UTMは素晴らしいQemuのフロントエンドだよ。 https://getutm.app/ https://mac.getutm.app/

すごい技術だね！QEMUでAndroidのVMを動かすのは無理だよね？公式にサポートされてるのかな？（Waydroidのことは知ってるけど）

└

Googleが提供してる公式のAndroid「エミュレーター」はqemuだよ。何か理由があってそれに満足できないなら、数年前にこれらのイメージをバニラのqemuの上で使ったことがあるんだけどね： https://www.fosshub.com/Android-x86.html もうあまりサポートされてないみたいだし、プリビルドの代替品もあまりないよ。でも、AOSPをソースからコンパイルすることはできるけど、Googleはそれを簡単にはしてくれないね。

└

うん、可能だしサポートもされてるよ。QEMUはaarch64システムをエミュレートできるし、Googleは特に仮想マシン用のaarch64 Androidビルド「Cuttlefish」を提供してるんだ。指示が必要なら「Android Cuttlefish QEMU」で検索してみて。

MIPS版のWindows NTがあったなんて知らなかった。これでWikipediaを見に行ったら、過去にサポートされていた他のアーキテクチャもたくさんあったよ。

QEMUがArmやRISC-Vのようなx86(_64)のハードウェアパスをサポートすることがあるのか気になるな… ほとんどの特許が今は切れてるから、すごく理にかなってるよね。Appleは他の競合よりもここで進んでるみたいだけど、Rosettaに限られてるみたいで、広くサポートされてるわけじゃないみたい。