In this post, I’d like to summarize what I did for bare-metal OSv, or OSp.

Fortunately, if you give up using some functions that rely on Virtio devices (e.g., networking), OSv is already capable of running on bare-metal with only two small fixes.

First, you need to skip AcpiReallocateRootTable() in drivers/acpi.cc. In this function, something causes triple fault and prevents OSv from booting up.

Second, you had better insert sleep() to wait for AHCI port linkup. Without it, OSv often mistakenly believes that AHCI ports won’t get ready.

The remaining tasks for bare-metal OSv are straightforward.

First, build the OSv’s disk image.

Then, you will get the image, build/release.x64/usr.img, which is in the QCOW2 format. So, next, convert it to the raw image (e.g., named bare.img).

Then, start your favorite OS on the target physical machine, on which bare-metal OSv is supposed to run, without mounting the primary local disk (e.g., you can use USB booting or network booting), and simply dd the bare.img you’ve just created onto the primary local disk.

Finally, restart the target physical machine from the local disk. OSp will show up

ONE MORE THING…

Since I’m tired of dd-ing OSv’s kernel image to the local disk each time I modified the source code of OSv, I make OSv kernel network-bootable (as shown in the figure).

First, apply the patch. Then, try git submodule update because the patch adds iPXE as a submodule.

Next, make the network-bootable image of OSv.

Then, use the script, scripts/embed, to specify the command parameters you want to pass to OSv.

Now, you have two important files: build/release.x64/loader.bin (network-bootable OSv kernel iage) and build/release.x64/loader.ipxe (network-bootable iPXE image). The remaining steps are for allowing PXE/iPXE chain-loading using the two files.

Setup TFTP server and put the two files (loader.bin and loader.ipxe) on the TFTP directory. Also, setup DHCP server so that the target client machine can be properly instructed during PXE booting. In the configuration file of DHCP (typically dhcp.conf), specify loader.ipxe as the boot file name for the client machine.

(How to setup TFTP/DHCP servers are well described in this article, for example.)

Here is the example of DHCP/TFTP configuration:

Finally, starts the client machine enabling PXE booting. Flying OSp will show up

DEMO

In this movie, OSv performs network booting and lands on a physical machine (my HP server). I also applied the patch, which is for the physical 10GbE driver for OSv, so the OSv can also use network functions.

(Firmware initialization of my HP server takes more than a minute in that movie. Skip it if you are not interested in. Sorry…)

ENVIRONMENT

Because OSp runs on physical machines, things can be easily changed depending on underlying hardware. So, here I’ll note my server specification where I confirmed OSp ran. My HP server is ProLiant ML310e Gen8 v2 (Intel Xeon E3-1241 v3 @ 3.50GHz, PC3-12800E-11 4GB * 4, SAMSUNG HD103UJ 7200RPM 1T). Here I put the output of lspci, /proc/cpuinfo and hdparm -I on the server as a reference.

Also note that OSv has the AHCI driver but does not have drivers for other physical block devices such as SCSI or RAID controllers.

SEE ALSO

• OSb: OSv on BitVisor. http://www.slideshare.net/yushiomote/osb-osv-on-bitvisor
• OSb: OSv on BitVisor 2. http://www.slideshare.net/yushiomote/osb-osv-on-bitvisor-2
• OS*: OSv on *. http://www.slideshare.net/yushiomote/o-sp-revised

For some reasons, I need to get used to C++ including C++11, even C++14 possibly.

I’ve read some books of C++ and learnt basic things such as class, template, inheritance, capsulation, polymorphism, virtual functions, collections and some new features introduced in C++11 such as type reference, initializer lists, lambda expressions, smart pointers, rvalue references. Now I’m reading and modifying some open source programs written in C++ for practice.

Through the practice, I’ve added a simple piece of code to OSv, which is an Intel 10GbE driver. With this code, OSv can directly handle a physical 10GbE NIC if the host allows NIC pass-through. I’ve confirmed DHCP and ping succeed. (It is a kind of “Hello World” example program in C++, in which OSv can directly say “Hello” to physical LAN “World”.)

I put my dirty patch here.
(Revised ones: Intel 10GbE Driver and Pass-through Script)

USAGE

(Assuming that you have already compiled the patched OSv on KVM)

First, make sure that IOMMU is enabled by your BIOS and host OS.

Second, use the shell script (bindctrl), which is added by the patch, in order to remove the target 10GbE NIC from your host OS and make it ready for OSv. If your 10GbE NIC is located at Function #0 of Device #00 in Bus #07 with vendor ID 8086h and device ID 1528h, then the command will be:

Finally, run the python script with the special option (-a 07:00.0), which is also added by the patch, to start OSv with PCI pass-through.

The output will be:

TODO

• Use interrupts
• Use offloading
• Use header write back
• Use advanced descriptors
• …

COMPONENTS

• pf class describes a physical function of PCI device, which consists of ioreg, phyreg, tx_queue, rx_queue classes.
• ioreg class describes a full set of I/O registers of the pf
• phyreg class describes a full set of PHY registers of the pf, which can be accessed through MSCA/MSRWD registers.
• tx_desc_layout struct is exactly a data structure of a TX descriptor.
• rx_desc_layout struct is exactly a data structure of a RX descriptor.
• desc template abstracts a descriptor, which is a template that depends on the descriptor types (tx_desc_layout or rx_desc_layout).
• tx_desc class abstracts a TX descriptor, which is derived from desc with TX descriptor type, tx_desc_layout.
• rx_desc class abstracts a RX descriptor, which is derived from desc with RX descriptor type, rx_desc_layout.
• queue template describes a queue, descriptors of which depends on the descriptor types (tx_desc or rx_desc).
• tx_queue class behaves as a queue with RX descriptors but also supports transmission operations that manipulate the queue.
• rx_queue class behaves as a queue with TX descriptors but also supports reception operations that manipulate the queue.

こちら 自作 OS Advent Calendar 2014 の 21 日目の記事です．

ハードウェアにいくつかの適当な仮定をおいて簡単な OS の断片（以下，OScrap （おぉスクラップ）と呼びます）を作りました．コンセプトもぼんやりしておりますが，とりあえず OScrap はサーバ用途 x86 OS です．アプリケーション側にはメモリ管理とネットワーク送受信の API だけを提供します．OScrap はアプリケーション含めシングルアドレス空間，シングル CPU モード (Ring 0) で，完全にポーリングベースで動作し，NIC はごく一部の高性能なもの 10GbE, 40GbE だけを仮定して VMDq などの NIC 側の多重化機能を前提にしてたくさんあるコアがあまり協調せず並列動作することを考えています．今後，OScrap 上に何らかのサーバアプリケーションを実装して遊ぶ予定です（試しに In-memory database とか．）．今のところ KVM 上と実機（Xeon E3-1241 / 16GB) で動作確認をしております．

目次

• 特徴
• 実装状況
• ソースコードと使い方
• ソースファイルの説明

特徴

以下，現時点での OScrap の特徴について説明します．

• 特徴 1) ローカルディスクなんてなかった．

PXE/iPXE での起動を前提にします．BIOS 環境でローカルディスクから起動すると通常，一番最初のコードは MBR 512 バイトに制限されますが， PXE/iPXE だと 512 バイトより多く読み込んでくれるので（少なくとも 480 KiB ぐらいはいいのかな？），いきなり OScrap カーネル本体がネットワーク越しに起動します．よって，OScrap には，一般的な OS のブートローダでよくある INT13h でカーネルを段階的に読み込むフェーズはありません．

• 特徴 2) 32-bit Protected Mode なんてなかった．

OScrap は起動すると Real-mode から大して何も確かめず一氣に Long mode へ入ります．

• 特徴 3) 例外・割り込みなんてなかった．

OScrap の IDT はからっぽです．NMI はごめんなさい．デバイスはすべてポーリングで処理する氣です．

• 特徴 4) ページサイズとは 1 GB だった．

1 GB ページング前提で動作し，起動時に 12 KiB のページテーブルを構築し 512 GB のメモリ領域を恒等写像でマップします．また，MMIO 用途として，仮想アドレス 512 + X GB は，物理アドレス X GB へキャッシュしない設定でマップします．ページフォルトなんてなかった．

• 特徴 5) APIC なんて最初から x2APIC だった．

x2APIC 前提で IPI 周りの処理をします．

• 特徴 6) ネットワークデバイスは Intel x540 10GbE しかなかった．

Intel x540 10GbE のドライバだけを持っています．VMDq サポート前提で VMDq 有効化し，64 個ペアの送受信インターフェースを提供します．（将来的には 40GbE のドライバを持つ予定です．）

• 特徴 7) 外部へのインターフェースはネットワークしかなかった．

デバッグ用にシリアル出力しますが，あくまでデバッグ用のつもりです．必要なものはネットワークで受け渡しすればいいというつもりです．

実装状況

• 現状，OScrap はメモリ管理とネットワーク送受信（L2）の API を持っているだけです．今後，main.c/main(), init.c/init_ap() 以下に処理を書き加えて何か役に立ちそうなアプリケーションを作ろうと思います．
• メモリ管理は liballoc を利用させて頂きました．また，実はページのアロケーションが適当で空いたページを解放しません（コード参照）．
• バグバグしているかもしれません．

ソースコードと使い方

コードは こちら になります（いずれはレポジトリへ）．KVM 上で実行するにはダウンロードしたものを展開して make run するだけです．前述の通り，CPU が 1GB ページング，x2APIC などに対応していないとちゃんと動作しません．ちなみに KVM 上では Intel X540 をパススルーにしないと OScrap はネットワーク通信できません．

KVM 上での実行結果は以下のようになります．現在デフォルトの OScrap アプリケーションは 3 秒数えて終了します．

OScrap を実機で動作させたい場合は，OScrap をネットワークブートさせます．そこでサーバ側でまず PXE/iPXE の設定を行ないます．

はじめに PXE のための DHCP の設定をします．ファイル “undionly.kpxe” を PXE ブートするように設定します．よくある BOOTP の設定です．

次に PXE のための TFTP の設定をします．よくある TFTP の設定です．

続いて iPXE の準備です．

最後に OScrap のバイナリを TFTP ディレクトリへ．

以上，準備ができたら OScrap を動作させる実機を TFTP/DHCP サーバとネットワーク的につないだ状態で再起動します．これで実機上で OS が実行されます．

x540 10GbE 搭載実機上で Debug 出力を全部有効にして実行すると以下のようになります．

ソースファイルの説明

• acpi.{ch} : ACPI テーブルを見つけてコアの数を数えたり，タイマーを見つけたりします．
• alloc.{ch} : liballoc を使います．
• apic.{ch} : x2APIC で IPI を飛ばして AP を起動させるコードです．
• init.{ch} : 各種初期化処理を順番に呼び出すコードです．
• kvi.ld : 0x7c00 から実行されるバイナリを生成するリンカスクリプトです．
• loader.S : 最初に実行されるアセンブラのコードです．OScrap の IDT, GDT の設定，ページングの設定，CPU モード遷移はここで完結します．
• main.c : アプリケーションの始まりとなる関数 main() が入っています．
• Makefile : OScrap のコンパイルや，QEMU/KVM 上での実行のためのコマンドが入っています．
• page.{ch} : ページを割当・解放するコードです．（解放は実は TODO．）
• printf.{ch} : printf です．
• putchar.{ch} : シリアルポートから文字をデバッグ用に出力します．
• timer.{ch} : デバイスを初期化する際の sleep を実装するためのタイマーの実装が入っています．HPET を使います．
• drivers/hpet.{ch} : HPET を初期化して使うコードです．割り込みは設定せずに，ただのカウンタとして使います．
• drivers/ixgbe.{ch} : Intel X540 10GbE Controller を初期化します．VMDq を有効化し，64 個の送受信機能を有効化します．
• drivers/pci.{ch} : PCI デバイスをスキャンするコードです．
• drivers/pmt.{ch} : ACPI Power Management を使うコードです．(結局，未使用)
• include/asm.h : C 言語からアセンブラ命令を呼ぶ必要がある時に使います．IO 命令や RDMSR, WRMSR などのインラインアセンブラです．
• include/common.h : よく使うヘッダファイルを束ねています．
• include/lock.h : ロックの処理です．
• include/msr.h : MSR の番号のマクロです．
• include/panic.h : panic 用関数ですが，ただ busy ループに突入するだけのスタブです．
• include/string.h : 文字列操作系関数です．（簡易実装）
• include/types.h : OScrap 全体で使われる型の定義です．
• include/mmio.h : MMIO のための関数です．(512GB + X へアクセスするだけ．)