2010年12月5日日曜日

FreeBSD + KVMの環境でちょっと過ごしてみてわかってきたノウハウ(1)

最近 FreeBSD 用の virtio ドライバに割と情熱を注いでいるのですが(そろそろ公開したい!)、
ドライバの性能が出ないという状況になって調査したときに多少ノウハウが得られたのでメモがてら掲載しておきます。

まずの一つ目のネタ。kvm_statコマンド。

kvm statistics

 efer_reload                  0       0
 exits                401230913    2152
 fpu_reload               52997       0
 halt_exits           133189538     757
 halt_wakeup            5259576      15
 host_state_reload    170030018     977
 hypercalls                   0       0
 insn_emulation       252392427    1359
 insn_emulation_fail          0       0
 invlpg                 2684292       0
 io_exits               4130425      17
 irq_exits              8935347      39
 irq_injections         3195682       0
 irq_window                   0       0
 largepages                   0       0
 mmio_exits            28482276     179
 mmu_cache_miss          698023       0
 mmu_flooded              40079       0
 mmu_pde_zapped          216076       0
 mmu_pte_updated         180285       0
 mmu_pte_write          1931218       0
 mmu_recycled                 0       0
 mmu_shadow_zapped       696204       0
 mmu_unsync                 877       0
 nmi_injections               0       0
 nmi_window                   0       0
 pf_fixed               4719781       0
 pf_guest                817765       0
 remote_tlb_flush        234452       0
 request_irq                  0       0
 signal_exits                 0       0
 tlb_flush              4903428       0

性能が出ていない場合には非常に参考になる内容です。ソースコードなどを見て何をしてくれているのか調査したわけではないのですが・・・





exits
発生したVMEXITすべての回数を示します。VMEXITとはIntel VT/AMD-VのCPU仮想化支援技術においてVMを実行し、何らかの理由(I/Oとかメモリ管理で何かがおきてVMMの介入が必要になったとか、タイムスライスを使い切ったとか色々)によりゲストを停止させた回数になります。仮想化支援技術があったとしてもVMMモード/ゲストモードの切り替えは非常にコストの高いものなので、これをいかに削減するかがポイントになります。



insn_emulation
それまでに発生したハードウェアエミュレーションの回数?を示しているようですが、細かいことは未調査。

io_exits

I/Oポートに対するアクセスで発生したVMEXITの回数を示します。
この値が大きくなる場合はハードウェアへのI/Oが頻発しており
性能劣化につながっていることが予想されます。
このような操作は全てVMEXITを引き起こしますので、いかにI/Oポートアクセスなどを少ない回数で済まさせるかが、VMの実質実効時間をのばすためにVMEXIT回数を削減するという観点で気になる数字です。

irq_exits

VMの実行中、物理ハードウェアにからの割り込みによってVMEXITした回数を示しているようです。この数字が大きい場合は物理ハードウェア側のIRQ割り込みをいかに減らすかの検討が必要になりそうです……。

irq_injections

ハードウェアエミュレータ(qemu-kvm)がVMに対して発行した割り込みの回数を示します。
IRQを使用している場合、IRQが発生すると、IRQをシェアするデバイスドライバ群が
ISR(Interrupt Status Register)をポーリングします。
このため割り込み回数×IRQ・・・と、共有するデバイス数が多いほどVMEXITの発生回数も増加にも繋がることから、ドライバを作るのであればこれをいかに低く抑えるかがポイントになります。

mmio_exits

メモリマップドI/OのためのVMEXIT回数です。

mmu_pte_write

シャドウページテーブル利用時、VM内のページテーブルのエントリ(Page Table Entry)を更新した数を示すようです。この値は、たとえばゲストOS上でmalloc()やfree()を行った場合にも実装次第で発生します。値が大きい場合は仮想マシン上のメモリ管理機構について再検討する余地があると言えます。この値はEPT/NPTが利用できないハードウェアでシャドウページテーブルによる負荷を見るのに利用できます。ここはゲスト内のプログラムのメモリ管理を工夫することで削減が可能です。ドライバなどであれば普段利用中にゼロから動かさせない、ぐらい高い目標を持ってもよいでしょう。


2010年10月20日水曜日

virtio for FreeBSD: Current Status (2010/10/20)

Hello World!
I decided to write virtio frontend drivers for FreeBSD because I wanted to understand how virtio works.
My virtio-net drivers began to work in the middle of October, so I'm guessing that I would offer the driver for FreeBSD community.
Actually there are some tasks to do before release it, so I need some time (and some help:).


Current Status (virtio-net)

  • virtio-net driver is working on a 1vCPU virtual machine. Tested more than 300GB of TX and RX.

  • almost same performance with e1000 (check out the graph below)

  • no offload functions provided (I think it is not so needed now)


Development Environment

  • Host: Fedora 14 alpha x86_64

  • Guest: FreeBSD 8.1-RELEASE, amd64


Least Required Tasks to offer this

  • non-indirect table mode support (needs test and debug)

  • split virtio PCI device framework and virtio-net driver

  • SMP support


If you're interested in development of virtio drivers in FreeBSD, please
contact me. I'm not a good kernel-hacker (actually this is my first
work for kernel mode program and also my first C work), so any help are
welcome.

vm162# ifconfig
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC>
        ether 52:54:00:1f:61:0d
        inet 192.168.44.162 netmask 0xfffffe00 broadcast 192.168.45.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3<RXCSUM,TXCSUM>
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
        inet6 ::1 prefixlen 128
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>

vm162# make load
/sbin/kldload -v /usr/src/sys/dev/xen/virtio/virtio_pci.ko
virtio_pci0: <virtio-net Virtual Network Interface> port 0xcb00-0xcb1f mem 0xf2054000-0xf2054fff irq 11 at device 8.0 on pci0
virtio_pci0: assigning PCI resouces: <1>mem <0>ioport <0>irq callback
virtio_pci0: [GIANT-LOCKED]
virtio_pci0: [ITHREAD]
vn0: Ethernet address: 52:54:00:1f:61:0e
Loaded /usr/src/sys/dev/xen/virtio/virtio_pci.ko, id=2

vm162# ifconfig vn0 up
vm162# ifconfig vn0 192.168.90.1 255.255.255.0
vm162# ifconfig
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC>
        ether 52:54:00:1f:61:0d
        inet 192.168.44.162 netmask 0xfffffe00 broadcast 192.168.45.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3<RXCSUM,TXCSUM>
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
        inet6 ::1 prefixlen 128
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
vn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 52:54:00:1f:61:0e
        inet 192.168.90.1 netmask 0xffffff00 broadcast 255.255.255.0

vm162# ping 192.168.90.2
PING 192.168.90.2 (192.168.90.2): 56 data bytes
64 bytes from 192.168.90.2: icmp_seq=0 ttl=64 time=3.696 ms
64 bytes from 192.168.90.2: icmp_seq=1 ttl=64 time=1.004 ms
64 bytes from 192.168.90.2: icmp_seq=2 ttl=64 time=1.051 ms
64 bytes from 192.168.90.2: icmp_seq=3 ttl=64 time=1.044 ms
64 bytes from 192.168.90.2: icmp_seq=4 ttl=64 time=1.218 ms
64 bytes from 192.168.90.2: icmp_seq=5 ttl=64 time=0.970 ms
^C
--- 192.168.90.2 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.970/1.497/3.696/0.986 ms

vm162# iperf -c 192.168.90.2
------------------------------------------------------------
Client connecting to 192.168.90.2, TCP port 5001
TCP window size: 32.5 KByte (default)
------------------------------------------------------------
[  3] local 192.168.90.1 port 15185 connected with 192.168.90.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.7 sec   142 MBytes   112 Mbits/sec
vm162#


performance comparison between fxp(e1000) and vn(virtio)


2010年10月12日火曜日

FreeBSD用virtioドライバを作ってみた

なんとなくノリで「virtioのドライバを書いてみたくなった」ので9月末から作業を開始したのですが、この週末で大体動くようになりました。


コードが整理できたら、FreeBSDソースツリーへのコミット目指して頑張ってみますかねぇ。まぁ、予定は未定です。また、実際にドライバが書ける程度まではvirtioを研究したので、また機会を見て情報共有できればと思っています。


■ どんなかんじ?



見てもらうのが早いですよね。こんなかんじ。

vm162# ifconfig
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC>
        ether 52:54:00:1f:61:0d
        inet 192.168.44.162 netmask 0xfffffe00 broadcast 192.168.45.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3<RXCSUM,TXCSUM>
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
        inet6 ::1 prefixlen 128
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>

vm162# make load
/sbin/kldload -v /usr/src/sys/dev/xen/virtio/virtio_pci.ko
virtio_pci0: <virtio-net Virtual Network Interface> port 0xcb00-0xcb1f mem 0xf2054000-0xf2054fff irq 11 at device 8.0 on pci0
virtio_pci0: assigning PCI resouces: <1>mem <0>ioport <0>irq callback
virtio_pci0: [GIANT-LOCKED]
virtio_pci0: [ITHREAD]
vn0: Ethernet address: 52:54:00:1f:61:0e
Loaded /usr/src/sys/dev/xen/virtio/virtio_pci.ko, id=2

vm162# ifconfig vn0 up
vm162# ifconfig vn0 192.168.90.1 255.255.255.0
vm162# ifconfig
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC>
        ether 52:54:00:1f:61:0d
        inet 192.168.44.162 netmask 0xfffffe00 broadcast 192.168.45.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3<RXCSUM,TXCSUM>
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
        inet6 ::1 prefixlen 128
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
vn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 52:54:00:1f:61:0e
        inet 192.168.90.1 netmask 0xffffff00 broadcast 255.255.255.0

vm162# ping 192.168.90.2
PING 192.168.90.2 (192.168.90.2): 56 data bytes
64 bytes from 192.168.90.2: icmp_seq=0 ttl=64 time=3.696 ms
64 bytes from 192.168.90.2: icmp_seq=1 ttl=64 time=1.004 ms
64 bytes from 192.168.90.2: icmp_seq=2 ttl=64 time=1.051 ms
64 bytes from 192.168.90.2: icmp_seq=3 ttl=64 time=1.044 ms
64 bytes from 192.168.90.2: icmp_seq=4 ttl=64 time=1.218 ms
64 bytes from 192.168.90.2: icmp_seq=5 ttl=64 time=0.970 ms
^C
--- 192.168.90.2 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.970/1.497/3.696/0.986 ms

vm162# iperf -c 192.168.90.2
------------------------------------------------------------
Client connecting to 192.168.90.2, TCP port 5001
TCP window size: 32.5 KByte (default)
------------------------------------------------------------
[  3] local 192.168.90.1 port 15185 connected with 192.168.90.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.7 sec   142 MBytes   112 Mbits/sec
vm162#


■ ベンチマーク

非常にいい加減なベンチマークですが、デフォルト設定の e1000 エミュレーションより微妙に速いようです。





e1000 オフロードエンジン等を ON/OFF すると性能が変わるようなので、まぁだいたい同じぐらいのパフォーマンスが出ていると考えればよさそうです。

■ 実装状況


  • ロック皆無!たぶん……いや、間違いなく、SMPだと即死します。

  • virtio PCIインターフェイスとvirtio-netがまだ綺麗に分離できていない。

  • キャパビリティ (features bit)のほとんどは未実装

■ その他今後の課題


  • virtio デバイスを実装するためのフレームワーク検討

  • ハードウェア チェックサム、その他キャパビリティのサポート

  • 一部 GPL ライセンスされたコードが含まれるため除去

  • 安定性の向上

  • チューニング

■ 作業環境


  • Host: Fedora 14: Fedora release 14 (Branched) Alpha Release, x86_64

  • Guest: FreeBSD 8.1-RELEASE, amd64

2010年9月23日木曜日

shadow_memory

 シャドウページテーブルのサイズ(MB)を指定します。明示的に指定しない場合
は必要な容量が自働確保されます。


■ ドメイン


  • 完全仮想化ドメイン(HVM)


■ 書式

shadow_memory=<n>


■ 必要なシャドウメモリの容量


  • 準仮想化ドメイン …… 不要

  • HVM ドメイン(x86、x86_64)…… 256 ×仮想CPU 数+ 2 ×最大メモリ量(MB)ページ
      (1 ページ= 4KB)

  • HVM ドメイン(IA-64)…… 不要


■ 例

memory=1024
shadow_memory=8


■ 注意点


  • 本情報はXen 3.4.0時点の内容です



xen_platform_pci

Xen プラットフォームPCI デバイスの有効・無効を指定します。本デバイスは、Xenのパラバーチャルドライバの利用するために必要です。

■ ドメイン


  • 完全仮想化ドメイン(HVM)


■ 書式

xen_platform_pci=<n>

■ <n>の値


  • 1 …… 有効

  • 0 …… 無効


■ 例

xen_platform_pci=1


■ 注意点


  • Xen プラットフォームPCI デバイスは、HVM ドメイン上のゲストOS がXen ハイパーバ
    イザと通信するために使用するものです。



2010年9月22日水曜日

PyGRUBで快適!OpenSolaris on Xenライフ

PyGRUBとは、Xenの準仮想化ドメイン(PV)で利用できるブートローダです。PyGRUBを使用すると、ドメイン起動時にゲストOSのディスクイメージ上から必要なファイル(カーネルおよびRAMディスクイメージ)を読み出して起動することができます。これにより、ドメイン起動にあたりdomain-0のファイルシステム上へゲストのカーネルファイルなどに事前準備する必要がなくなりkernel行とextra行に具体的な値を記述する必要がなくなります。


PyGRUBは多数のファイルシステムをサポートしており、最近のバージョンでは、なんとOpenSolarisのZFS上のGRUB設定ファイルを使って純仮想化ドメインを起動できます。




■ PyGRUBとpv-grub

同種のツールとしてはpv-grubがあります。PyGRUBもpv-grubも基本的にやってくれる事は同じなのですが、PyGRUBはPythonベースのもどきスクリプトであるのに対してpv-grubは準仮想化ドメイン向けにportされたGRUB(つまり、ブートローダの機能としてはx86の物理マシンで使われているものをXenに対応させたもの)である、という違いがあります。ただ、Xen 3.4.2に含まれるpv-grubではZFSを扱えないようです(しっかり確認したわけではないのですが)。

なお、現在ではPyGRUBの利用は推奨されていません。なぜなら、PyGRUBはdomain-0上で動作するプログラムであり、細工されたdomain-Uイメージを処理させることによりdomain-0への干渉を許す可能性があるためです。pv-grubはブートローダの処理自体がDomain-U上で動作するため、いくらかセキュリティ面において優位性があります。


■ OpenSolaris のブートに必要なファイルとパラメータ


OpenSolarisをPVドメインとして動作させる際に必要なものとして、下記のファイルとパラメータがあります。


unix ファイル …… OpenSolarisのカーネル

boot_archive ファイル …… RAMイメージ
ルートファイルシステムとしてマウントするファイルシステムの位置情報


カーネル、およびRAMイメージのファイルはOpenSolarisのファイルシステム上にあるものですので、これをLinuxで動作するdomain-0のファイルシステム上にコピーするのはそれほど難しいことではありません。また、ルートファイルシステムの場所は、OpenSolarisのファイルシステム上にあるGRUBの設定ファイルを見れば解決可能です。


しかし、実際に運用をはじめると、カーネルやRAMイメージをゲストのファイルシステムから適宜抽出したり、もしくはBoot Environmentを作成/更新するたびにbootfsの値をドメインの定義ファイルに書くのは煩雑な作業となります。


■ PyGRUBを使ったOpenSolarisの起動


では早速PyGRUBを使ってOpenSolarisを起動してみましょう。以下にドメイン定義ファイルの記述例を示します。


PyGRUBを使用しない場合の例(参考)

kernel="/boot/os200811/unix"
ramdisk="/boot/os200811/boot_archive"
extra= '/platform/i86xpv/kernel/amd64/unix –B 
    zfs-bootfs=rpool/52,bootpath="/xpvd/xdf@0:a"’

PyGRUBを使用する場合の例

bootloader="/usr/bin/pygrub"


いかがでしょうか?ドメイン定義ファイルの内容が非常にすっきりしたことでしょう。

この方法を使うと、OpenSolarisのPVドメインを、ゲストのファイルシステム上にある最新カーネル、およびbeadmで実際にアクティブ化されているBEから自動的に起動することが可能です。

■ Live CDの起動にも使える

PyGRUBはZFSをサポートしていますが、そのほかISO9660もサポートしていますので OpenSolaris LiveCD をPVで起動するためにも使えます。

access_control

ドメインのセキュリティポリシーおよびラベルを指定します。


■ ドメイン


  • 準仮想化ドメイン(PV)

  • 完全仮想化ドメイン(HVM)


■ 書式

access_conrtol='policy=<policy>,label=<label>'


■ パラメータ


  • policy …… ドメインに割り当てるセキュリティポリシー

  • label …… ドメインのラベル名


■ 注意点


  • 本情報はXen 3.4.0時点の内容です