Virtioについて

Linux KVMについて

KVM(Kernel-based Virtual Machine)はLinuxカーネルを仮想マシンの実行環境（要するにハイパーバイザ）として提供するためのカーネルモジュールである。これはカーネルモジュールなのでOSのメモリ管理やプロセススケジューリングなどを積極的に活用して、効率的な仮想化環境を提供できる。
KVMはCPUの仮想化支援機能を用いて仮想マシンを作ることができる。この仮想マシンには仮想CPUが搭載されている。通常、ソフトウェアでエミュレートしたCPUを使うと、実際のCPUで一つの命令で済む場合でも、何十もの命令に置き換えられてしまう（エミュレートして実際のCPUが実行するから）ので、性能が著しく低下する。
しかし仮想化支援機能によって、仮想マシン内の命令実行がホストマシンの物理CPUに直接移譲され命令が実行される。

すなわち、KVMを使う最大の利点はCPUの仮想化支援技術を利用して、効率的な命令実行ができることにある。

QEMUについて

QEMUは仮想マシンソフトウェア（ユーザーアプリ）であり、CPU、メモリ、I/Oデバイスなどのハードウェアコンポーネントをエミュレートすることができる。
普段のOS開発でお世話になってるやつ。これ単体で仮想マシンとして動かすことはできるが、先ほど述べたようにソフトウェアでエミュレートしたCPUはとても効率が悪い。

どのように協調するのか

KVMによって仮想CPUを提供し、QEMUによってメモリやI/Oデバイスを提供するようにすることで、CPUの仮想化支援技術を用いてCPUの命令を効率よく実行しつつ、QEMUによってエミュレートされたメモリやI/Oデバイスを使用できる。

雑なイメージ

junyaU 22日前

qemuに-enable-kvmオプションを付けて実行するとkvmがCPUのエミュレーションを行ってくれる。

junyaU 22日前

差を比べたいから自作OSで軽いベンチマークとってみようかな

なんかちょっとQEMUの見た目変わる
QEMUonlyの場合

QEMU&KVMの場合

qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]

kvmと実行したら警告が出た。pcの仮想化設定が有効になってないのかな

いや有効やけどなあ

-cpu hostオプション付けたら警告消えた。

junyaU 21日前に更新

ゲストOSの準仮想化（Virtio）デバイスドライバがVirtio queuesにパケットを送信する。
送信後にデバイスドライバがKVM（ハイパーバイザ）に処理を渡す（ここでVMExitが発生）
KVMはQEMUのタスクをスケジューリングする
QEMUは、Virtio queuesからメッセージを受け取りI/Oデバイス（ネットワークデバイス）のエミュレートをして、Virtio queuesにパケットを送ったり送らなかったりする
ゲストOSに制御が戻り、Virtio queuesに格納されているデータを処理する

junyaU 21日前に更新

Intel VT-xについて

junyaU 21日前に更新

プロセッサが、仮想マシンの実行からハイパーバイザの実行に切り替わることをVMExitという。
このVMExitは、仮想マシンの実行におけるオーバーヘッドになる。
完全仮想化のデバイスが遅い理由はここにあり、エミュレートされたデバイスのハードウェアレジスタに対するアクセスが検知されるたびにVMExitが走るらしい。
準仮想化デバイスの場合、ゲストOSがキューにメッセージを送ってKVMにトラップするときぐらいしか使われないみたい。VMExitの抑制になるから結果的に早くなるのかな。

junyaU 21日前

Virtioは準仮想化デバイスとはいえ、ハイパーバイザ上でなければ実現できないような挙動には依存しない。

virtqueueは以下の領域を持つ。

ディスクリプタエリア

ドライバが各処理要求のディスクリプタチェーンのアドレスや長さを書き込む場所

ドライバエリア

仮想デバイスに処理してほしいディスクリプタチェーンの先頭を書き込むリングバッファ。

デバイスエリア

デバイスが処理を完了したディスクリプタチェーンの先頭が書き込まれるリングバッファ。ドライバはここから処理要求の結果を見る。

virtioの仕様書結構見やすくてありがたい

ドライバがデバイスを初期化する流れ

Reset the device.
Set the ACKNOWLEDGE status bit: the guest OS has noticed the device.
Set the DRIVER status bit: the guest OS knows how to drive the device.
Read device feature bits, and write the subset of feature bits understood by the OS and driver to the device. During this step the driver MAY read (but MUST NOT write) the device-specific configuration fields to check that it can support the device before accepting it.
Set the FEATURES_OK status bit. The driver MUST NOT accept new feature bits after this step.
Re-read device status to ensure the FEATURES_OK bit is still set: otherwise, the device does not support our subset of features and the device is unusable.
Perform device-specific setup, including discovery of virtqueues for the device, optional per-bus setup, reading and possibly writing the device’s virtio configuration space, and population of virtqueues.
Set the DRIVER_OK status bit. At this point the device is “live”.

それぞれのstatus

ACKNOWLEDGE (1)

Indicates that the guest OS has found the device and recognized it as a valid virtio device.

DRIVER (2)

Indicates that the guest OS knows how to drive the device. Note: There could be a significant (or infinite) delay before setting this bit. For example, under Linux, drivers can be loadable modules.

FAILED (128)

Indicates that something went wrong in the guest, and it has given up on the device. This could be an internal error, or the driver didn’t like the device for some reason, or even a fatal error during device operation.

FEATURES_OK (8)

Indicates that the driver has acknowledged all the features it understands, and feature negotiation is complete.

DRIVER_OK (4)

Indicates that the driver is set up and ready to drive the device.

DEVICE_NEEDS_RESET (64)

Indicates that the device has experienced an error from which it can’t recover.

PCIかMMIOからアクセスできそう。PCIのスキャンは既に実装してた気がするからPCIのほうからアクセスしてみよう

とりあえず検出したpciデバイス表示させたいから先にlspsiを実装する

VirtIOデバイスをQEMUに追加する場合、それぞれのデバイスに対応するディスクイメージが必要

これでvirtio-blkが認識されるようになった

qemu-system-x86_64 -m 1G \
    -drive if=pflash,format=raw,file=OVMF_CODE.fd \
    -drive if=pflash,format=raw,file=OVMF_VARS.fd \
    -drive if=ide,index=0,media=disk,format=raw,file=$disk_img \
    -device nec-usb-xhci,id=xhci \
    -device usb-kbd \
    -drive if=none,id=drive-virtio-disk0,format=raw,file=$storage_img \
    -device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk0 \
    -monitor stdio -S -gdb tcp::12345

雑に出力した

ベンダーIDが1AF4のベンダーはRed Hatであり、そのデバイスIDが1なのでVirtio block deviceが識別されていることがわかる。

junyaU 18日前に更新

lspciコマンドを雑に作った。検出できていないデバイス2個あるけどVirtioの実装一通り終わったら直そう

junyaU 17日前

Virtioで定義されている整数データ型
u8, u16, u32, u64 : 符号なし整数
le16, le32, le64 : リトルエンディアンの符号なし整数
be16, be32, be64 : ビッグエンディアンの符号なし整数

junyaU 17日前

Virtqueuesについて

The mechanism for bulk data transport on virtio devices is pretentiously called a virtqueue. Each device can have zero or more virtqueues.
Driver makes requests available to device by adding an available buffer to the queue, i.e., adding a buffer describing the request to a virtqueue, and optionally triggering a driver event, i.e., sending an available buffer notification to the device.
Device executes the requests and - when complete - adds a used buffer to the queue, i.e., lets the driver know by marking the buffer as used. Device can then trigger a device event, i.e., send a used buffer notification to the driver.
Device reports the number of bytes it has written to memory for each buffer it uses. This is referred to as “used length”.
Device is not generally required to use buffers in the same order in which they have been made available by the driver.
Some devices always use descriptors in the same order in which they have been made available. These devices can offer the VIRTIO_F_IN_ORDER feature. If negotiated, this knowledge might allow optimizations or simplify driver and/or device code.

junyaU 17日前

バージョン2.7以前の名称 → 現在の名称

Descriptor Table → Descriptor Area
Available Ring → Driver Area
Used Ring → Device Area

junyaU 17日前に更新

まずはvirtioデバイスの初期化処理から作るか。

このあたりからVirtio Over PCI Bus を使用する Virtio デバイスの仕様が書かれている

VirtioのPCIデバイスレイアウト

設定方法

I/O領域やメモリ領域を介して、デバイスの設定が行われる。これらの領域は、Virtio Structure PCI Capabilitiesによって指定される。
デバイス構成内のすべてのフィールドはリトルエンディアン。
64ビットフィールドは、二つの32ビットフィールドとして扱われる。

ドライバがアクセスするには

8ビットフィールドに対して、8ビット幅のアクセス。
16ビットフィールドには、16ビット幅でアラインしてアクセス。
32ビットおよび64ビットのフィールドに対しては、32ビット幅でアラインされたアクセス。
64ビットのフィールドは、ドライバが高い32ビット部分と低い32ビット部分をそれぞれ独立してアクセスできる。

Virtio Structure PCI Capabilities

Virtio Structure PCI Capabilitiesは、VirtioのPCIデバイスにおけるPCI Capabilitiesの領域を指す。
PCI CapabilitiesはPCIコンフィギュレーション空間における拡張領域。0x00から0x3FはPCIデバイス共通の設定が含まれており、0x40以降が拡張領域（これがPCI Capabilities）となる。

Virtioデバイスのコンフィギュレーションレイアウトは以下の構造体たちで構成されている。

Common configuration
Notifications
ISR Status
Device-specific configuration (optional)
PCI configuration access

これらの構造体は、BAR（Base Address Register）か VIRTIO_PCI_CAP_PCI_CFGというPCIコンフィギュレーション空間内の特別なフィールドからアクセスできる。

struct virtio_pci_cap { 
        u8 cap_vndr;    /* Generic PCI field: PCI_CAP_ID_VNDR */ 
        u8 cap_next;    /* Generic PCI field: next ptr. */ 
        u8 cap_len;     /* Generic PCI field: capability length */ 
        u8 cfg_type;    /* Identifies the structure. */ 
        u8 bar;         /* Where to find it. */ 
        u8 id;          /* Multiple capabilities of the same type */ 
        u8 padding[2];  /* Pad to full dword. */ 
        le32 offset;    /* Offset within bar. */ 
        le32 length;    /* Length of the structure, in bytes. */ 
};

PCI Capabilitiesに格納されているvirtio_pci_capのbar&offsetから該当のbarとそのオフセットを見つける→ barの特定オフセットにcfg_typeに応じた構造体が格納されている。
PCI Capabilitiesからvirtio_pci_cap を探すときは、cap_nextを走査するイメージ。

Common configuration

struct virtio_pci_common_cfg { 
        /* About the whole device. */ 
        le32 device_feature_select;     /* read-write */ 
        le32 device_feature;            /* read-only for driver */ 
        le32 driver_feature_select;     /* read-write */ 
        le32 driver_feature;            /* read-write */ 
        le16 config_msix_vector;        /* read-write */ 
        le16 num_queues;                /* read-only for driver */ 
        u8 device_status;               /* read-write */ 
        u8 config_generation;           /* read-only for driver */ 
 
        /* About a specific virtqueue. */ 
        le16 queue_select;              /* read-write */ 
        le16 queue_size;                /* read-write */ 
        le16 queue_msix_vector;         /* read-write */ 
        le16 queue_enable;              /* read-write */ 
        le16 queue_notify_off;          /* read-only for driver */ 
        le64 queue_desc;                /* read-write */ 
        le64 queue_driver;              /* read-write */ 
        le64 queue_device;              /* read-write */ 
        le16 queue_notify_data;         /* read-only for driver */ 
        le16 queue_reset;               /* read-write */ 
};

ドライバは以下のフィールドに書き込んではいけない。

device_feature
num_queues
config_generation
queue_notify_off
queue_notify_data

queue_enable で virtqueue を有効にする前に、他の virtqueue フィールドを設定しなければならない。

device_status に 0 を書き込んだ後、ドライバはデバイスを再初期化する前に device_status の読み込みが 0 を返すのを待たなければならない。

ドライバは queue_enable に 0 を書き込んではいけない。

Notifications

Notificationsは、VIRTIO_PCI_CAP_NOTIFY_CFGを使用して見つける必要がある。

struct virtio_pci_notify_cap { 
        struct virtio_pci_cap cap; 
        le32 notify_off_multiplier; /* Multiplier for queue_notify_off. */ 
};

virtqueue の BAR 内のキュー通知アドレスの求め方

cap.offset + queue_notify_off * notify_off_multiplier

ISR status

Virtio PCIデバイスにおいて割り込みステータスを管理するための特定の機能を提供する。このCapabilityにより提供されるISR（Interrupt Status Register）は、ドライバがデバイスからの割り込みを適切に処理するのに必要な情報を提供する。

PCIコンフィギュレーション空間内の特定のオフセットに配置される。このオフセットは、virtio_pci_cap 構造体の offset フィールドを通じて特定される。この構造体はbar フィールドによって指定されたBARを介してアクセスされる場合が多い。

ISRの構造

Bits	0	1	2 to 31
Purpose	Queue Interrupt	Device Configuration Interrupt	Reserved

ドライバが割り込みを受信したときにどこからの割り込みかを判断するためにISRステータスレジスタを読みだす感じか。

Virtio Structure PCI Capabilitiesはだいぶ理解が深まった

junyaU 13日前に更新

MSIとMSI-Xの違いをちゃんと理解していない（拡張版ってことしか知らん）

junyaU 12日前に更新

virtioの仕様としてサポートしているのがINTxとMSI-X。
仕様書にMSIの言及は特になし。

If MSI-X capability is disabled:
Read the ISR Status field, which will reset it to zero.
If the lower bit is set: look through all virtqueues for the device, to see if any progress has been made by the device which requires servicing.
If the second lower bit is set: re-examine the configuration space to see what changed.
If MSI-X capability is enabled:
Look through all virtqueues mapped to that MSI-X vector for the device, to see if any progress has been made by the device which requires servicing.
If the MSI-X vector is equal to config_msix_vector, re-examine the configuration space to see what changed.

あ、でも上記の仕様書の記載からMSIも使えそうな雰囲気が感じ取れる。

やっぱむりっぽい。MSI-Xの対応しなきゃかあ...めんどい

junyaU 12日前に更新

MSIについて

Trigger Mode

割り込み信号がどのように発生するかを定義する。

Edge Triggered : 割り込み信号のエッジ（信号の変化）が割り込みを発生させる。信号が低から高に変わる瞬間（立ち上がりエッジ）や、高から低に変わる瞬間（立ち下がりエッジ）に割り込みがトリガーされる。
Level Triggered : 割り込み信号のレベル（信号の状態）が割り込みを発生させる。信号が特定のレベル（高か低）に保持されている間割り込みがアクティブになる。

Delivery Mode

CPUに割り込みがどのように配信されるかを指定する。

Fixed : 固定配信モード。指定された特定のCPUコアに対して割り込みを配送する。このモードを使用することが一般的。
Lowest Priority : 最低優先度配信モード。MSIでは使わない。
SMI, NMI, INIT, ExtINT : MSIでは使わない。

junyaU 11日前に更新

MSI

Capability

Message AddressとMessage Dataは、Header部分の直後に配置されている。

MSI-X

Capability

Message AddressとMessage Dataは、BARで指定されるMMIO領域に配置されている。

MSI-X Table

各割り込みについての詳細設定を格納するテーブル。

Vector Control : 割り込みのコントロールオプション。割り込みのマスクとかも含まれていて個別の割り込みを動的に無効/有効にすることができる。
Message Data : 割り込みに関連するデータ（割り込みベクタとか）が含まれる。
Message Address : 割り込みが送信されるプロセッサのローカルAPICのアドレスなどを指定する。

MSI-X PBA Table

MSI-X PBA(Pending Bit Array) Tableはアクティブながらまだ処理されてない割り込みを追跡するためのテーブル。
ドライバや割り込みハンドラが割り込みを効率的に処理するために、どの割り込みがペンディング状態にあるかをすぐに確認できる。

共通している構造

Message Address Register

Message Data Register

junyaU 11日前に更新

大まかなMSI-Xの設定手順

PCIデバイスを検出する
Capability Pointerの取得
MSI-X Capabilityの探索
MSI-X Capabilityエントリから、MSI-X TableとPBA Tableのアドレス取得
MSI-X Tableの設定
割り込みの有効化

って感じか。意外とそこまで複雑ではなさそうだった

MSI-X Tableの格納されているBARとそのオフセットを取れた

PBA TableのほうはBARとオフセットともにゼロだった。これは、virtio_blkでは使わないということかな？

junyaU 11日前

msi_x_capabilityの設定コード書いてみた。動くかな。

void write_msi_x_capability(const device& dev,
                            const msi_x_capability& msix_cap,
                            uint64_t msg_addr,
                            uint32_t msg_data)
{
	uint64_t table_bar = read_base_address_register(dev, msix_cap.table_bar);

	auto* msix_table =
			reinterpret_cast<msix_table_entry*>(table_bar + msix_cap.table_offset);

	msix_table->msg_addr = msg_addr & 0xffffffffU;
	msix_table->msg_upper_addr = msg_addr >> 32;
	msix_table->msg_data = msg_data;

	// Memory barrier to ensure writes are not reordered
	asm volatile("mfence" ::: "memory");
}

junyaU 10日前

MSI-Xうまく動かないな...

junyaU 10日前

junyaU 9日前に更新

BARのオフセットとインデックスの取得方法を間違えている可能性がある

junyaU 9日前

見逃している設定があった。

The maximum table size is 2048 entries. Each 16-byte entry is divided in 4 fields as shown in the figure below. The MSI-X table can be accessed on any BAR configured. The base address of the MSI-X table must be aligned to a 4 KB boundary.

どうやらMSI-X tableのアドレスは4KiB境界アラインする必要があるらしい。

junyaU 3日前

長らく詰まっていたMSI-Xようやく機能した...

junyaU 2日前に更新

動かなかった原因

Specifies the memory address offset for the MSI-X Table relative to the BAR base address value of the BAR number specified in MSI-X Table BAR Indicator,[2:0] above. The address is extended by appending 3 zeros to create quad-word alignment.

オフセットを８バイト境界にアラインするために、左に3ビットシフトする必要があった。

uint64_t bar_addr = read_base_address_register(dev, msix_cap.table.bits.bar);
bar_addr &= 0xffff'ffff'ffff'f000U;
bar_addr += msix_cap.table.bits.offset << 3;
auto* table_entry = reinterpret_cast<msix_table_entry*>(bar_addr);

barのアドレスを4KIBアラインしたものと、オフセットを3bit左にシフトしたものを足すことで、MSI-X Tableのアドレスを得ることができた。もっとしっかり仕様書読むべきだったと反省。

junyaU 2日前

Virtio Structure PCI Capabilitiesはどこから取れるんだろうか。

junyaU 2日前に更新

PCIコンフィグレーション空間

0x34オフセットからcapability listを走査する。

走査してみた。cap_idが9のものがvirtioのcapability。ちなみに17(0x11)はMSI-X用のCapabilityである。

Capability読み込んでみたけどbar以降がちゃんと読み込めてない気がする