投稿

2018の投稿を表示しています

(続)kvm にハイパーコールを追加する

この記事の続き前回の記事では kvm にハイパーコールのハンドラを記述していたが,様々な事情でホストのユーザーランドでハンドリングしたいかもしれない。 今回はそのような場合の対処を書く。カーネルへの変更ベースのコードは Linux 4.18 ですまずはおさらい。このように vmcall の番号とハンドラを追加する。diff --git a/include/uapi/linux/kvm_para.h b/include/uapi/linux/kvm_para.h index dcf629dd2889..e0f8b786a62a 100644 --- a/include/uapi/linux/kvm_para.h +++ b/include/uapi/linux/kvm_para.h @@ -26,6 +26,7 @@ #define KVM_HC_MIPS_EXIT_VM 7 #define KVM_HC_MIPS_CONSOLE_OUTPUT 8 #define KVM_HC_CLOCK_PAIRING 9 +#define KVM_HC_TEST 100 /* * hypercalls use architecture specific diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 2b812b3c5088..5158880899f0 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -6740,6 +6740,10 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu) ret = kvm_pv_clock_pairing(vcpu, a0, a1); break; #endif + case KVM_HC_TEST: + ret = 0; + some_process(); + vcpu->run->exit_reason = K…

Rust で UEFI を使う最近の方法

uefi-rs を使うとかなりサクっと使えて良い。cargo build をするだけで UEFI Application が吐ける。 まず,cargo-xbuild をインストール。 $ cargo install xbuild これは私が以前から使っていた xargo の fork のようだ。 以下のようにそれぞれ準備する。

x86_64-uefi.json { "llvm-target": "x86_64-pc-windows-msvc", "target-endian": "little", "target-pointer-width": "64", "target-c-int-width": "32", "os": "uefi", "arch": "x86_64", "data-layout": "e-m:e-i64:64-f80:128-n8:16:32:64-S128", "linker": "rust-lld", "linker-flavor": "lld-link", "pre-link-args": { "lld-link": [ "/Subsystem:EFI_Application", "/Entry:efi_main" ] }, "panic-strategy": "abort", "default-hidden-visibility": true, "executables": true, "position-independent-executables": true, "exe-suffix…

virt-install で kickstart を使う

Red Hat のサイトの日本語資料は嘘があってダメだった

具体的には, virt-install で ks.cfg を --initrd-inject オプションで渡し,--extra-args "inst.ks=file:/ks.cfg" とするなどと書かれているが,実際にこれを使うと No such file or directory などと言われる。 次のように ks.cfg のディレクトリで http server を起動し, $ python -m http.server 8000 そのあと次のようにインストールする(設定はお好みで) virt-install --connect=qemu:///system --name Fedora27 --hvm --virt-type kvm --ram 4096 --vcpus 4 --arch x86_64 --os-type linux --os-variant fedora27 --disk pool=default,size=5,format=qcow2,bus=virtio --network bridge=br0,model=virtio --graphics none --serial pty --console pty --location /iso/Fedora-Server-dvd-x86_64-27-1.6.iso --extra-args "inst.ks=http://:8000/ks.cfg console=tty0 console=ttyS0,115200n8" Red Hat の日本語サイトのドキュメントはちょくちょく古い情報があって更新されていないので,よくひっかかってしまう。

kvm にハイパーコールを追加する

Stack Overflow のこの投稿 https://stackoverflow.com/questions/33590843/implementing-a-custom-hypercall-in-kvm のほぼそのままです。 いつもググるか grep でコードの場所を探してしまうので備忘録。 diff --git a/include/uapi/linux/kvm_para.h b/include/uapi/linux/kvm_para.h index dcf629dd2889..e0f8b786a62a 100644 --- a/include/uapi/linux/kvm_para.h +++ b/include/uapi/linux/kvm_para.h @@ -26,6 +26,7 @@ #define KVM_HC_MIPS_EXIT_VM 7 #define KVM_HC_MIPS_CONSOLE_OUTPUT 8 #define KVM_HC_CLOCK_PAIRING 9 +#define KVM_HC_TEST 100 /* * hypercalls use architecture specific diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index b7618b30b7d6..5c82ac8f4b38 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -6714,6 +6714,9 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu) ret = kvm_pv_clock_pairing(vcpu, a0, a1); break; #endif + case KVM_HC_TEST: + some_process(); + break; default: ret = -KVM_ENOSYS; break; このように,ハイパーコールの番号を追加し,アーキテクチャ固有のコードにハイパーコールの番号で switch している箇所があるのでそこ…

CPU の定格クロックを取得する(IA-32,Intel 64 限定)

Intel CPU の場合 cpuid 命令で取得できる諸情報のうち processor brand string という CPU のブランド名を取得する命令を使うことによって,このブランド名文字列の末尾にある文字列を見れば良い。

実のところ /proc/cpuinfo の model name の行を見るのと同じだが,Linux 以外でも使えるなど色々あって /proc を舐めたくないときがあります(本当?) #include <cstdint> #include <cstdio> #include <string> #include <iostream> #include <algorithm> // CPU 周波数を processor brand string に記述されている周波数から取得する int main(int argc, char* argv[]) { struct reg{ uint32_t eax,ebx,ecx,edx; } r; std::string processor_brand_string = {}; // brand string を取得して processor_brand_string へ格納 __asm__ volatile("cpuid" : "=a"(r.eax), "=b"(r.ebx), "=c"(r.ecx), "=d"(r.edx) : "a"(0x80000002), "c"(0x0)); processor_brand_string.append(reinterpret_cast(&r), 16); __asm__ volatile("cpuid" : "=a"(r.eax), "=b"(r.ebx), "=c"(r.ecx), "=d"(r.edx) …

journalctl の使い方 Tips

そろそろ多くの環境が systemd になったかと思います。
systemd 環境では syslog や logrotate が systemd-journald で管理されるようになっており,journalctl を使うと便利にログを眺められます。

私は systemd 環境を主に使い出して 6 年ぐらいになるのですが途中にオプション増えたりコマンド増えたり色々ありました。そんなわけで,journalctl コマンドを使うときの便利なオプションとかのメモ,いってみよー

ブート ID の一覧と特定の起動時のログの表示$ journalctl --list-boot -5 f5b4ff9349204d31b7c89cae00a765e5 Fri 2018-06-01 12:32:20 JST—Fri 2018-06-01 12:33:43 JST -4 1baea4095c424e6b8f50f3eff1af2161 Fri 2018-06-01 12:34:21 JST—Fri 2018-06-01 12:35:17 JST -3 dfb54ab05bd14c05ae83f4a767492293 Fri 2018-06-01 12:38:43 JST—Fri 2018-06-01 12:40:28 JST -2 336d9d0421ce44d59aadcaf2de634e92 Fri 2018-06-01 12:50:57 JST—Tue 2018-06-05 10:15:33 JST -1 676a0fbbf09948bcbb18e5f61d27f51b Tue 2018-06-05 11:28:20 JST—Tue 2018-06-05 13:55:23 JST 0 92feec044ea94d88a6f95548df223f80 Wed 2018-06-06 00:51:40 JST—Wed 2018-06-06 00:57:37 JST これまで logging した boot ID の一覧を出してくれます。これで,「あ,一昨日起動したときのログが見たいなー。一昨日起動したのは二回前の起動のときかー」ってなったら,
$ journalctl -b -2 とすればいいわけです。ちなみに,単に今起動している分のログだけ見たい場合…

Linux カーネルおさんぽマップ〜時計編〜

イメージ
本稿では,Linux カーネルで扱える時計のうち,PTP(Precision Time Protocol)という IEEE 1588 で策定されている高精度な時計をクロックソース[1]にする場合について追っていこうと思います。
Linux における時刻同期:NTP と PTP Linux や Windows,macOS といった現在の OS のシステムクロックは,一般的にはインターネットを通じて NTP(Network Time Protocol)が同期するようになっています。
NTP を使っていればインターネットに接続されている際には大きく時刻がズレることはなく,たまにネットワーク接続が失われていてもクォーツ時計は安物の振り子式ほど時間はズレません。

では,NTP は設計としてどのくらいの誤差が考えられているのでしょうか。NTP の設計者 David L. Mills 博士は自身が実装した PDP-11 向けの OS「Fuzzball」上の実験でそれを示しており,答えは数十ミリ秒です[2]。現代のマシンと OS ならば数ミリ秒までは迫れるかもしれません。ちなみにこの論文が発表された翌年には NTP version 2 が RFC から発行されています[3]。(現在は version 4。)

NTP は日常的な利用には十分な精度があります。しかし,マイクロ秒やナノ秒といった単位での高精度さが目的ではありません。日本の NTP のサーバーとして有名な NICT(情報通信研究機構)は日本標準時の決定をしており原子時計も所有していますが,インターネットを介して NICT などのサーバーにアクセスしている時点でミリ秒やひどいときは数秒の遅れが発生するでしょう。LAN に NTP サーバーがあったとしても,アルゴリズムとして数ミリ秒の遅延を許容しています。そこで高精度な時刻同期のために存在するのが PTP です。
PTP とは PTP とは,ネットワークデバイス内の時計を高精度に同期する仕組みです。グランドマスタークロックと呼ばれる時計をマスターとして設置し,LAN の NIC たちがそれを元に同期するといったような仕組みになります。これによって,パケットのタイムスタンプをハードウェアで高精度に打つことが可能になったり,この PTP をクロックソースとしてシステムクロックを…

Atom のマシンと Xeon のマシンで 10 Gbit Ethernet の帯域測定

イメージ
タイトル通りです。

Intel 82599ES 10-Gigabit SFI/SFP+ を搭載した二台のマシンを DA ケーブルで直結し,iperf3 で測定を行なってみました。

マシンの性能は次の通り。
Atom のマシン

Xeon のマシン

搭載されているメモリ量,メモリ速度は同じ,NIC も同じ。
CPU の性能が大幅に異なります。
さて,それでは測定結果をみてみましょう。

まずは Atom が client(送信側),Xeon が server(受信側)の場合。
上から帯域,congestion windowのサイズ,リトライ回数で,x 軸が時間軸です。帯域はほぼ 9.40 Gbits/sec 前後をキープしており,期待に近い結果が得られていると思います。リトライ回数は全てゼロ。

次に Xeon が client(送信側),Atom が server(受信側)の結果です。
悲惨ですね。まず目に見えてリトライ回数が多いです。ワーストケースで 98 回もリトライしていました。また,congestion window のサイズも変化しまくり,約 1.2 MB にまでなる場合も。従って,帯域もラインレートからほど遠い 6.43 Gbits/sec を叩き出しています。おうちで宅内の LAN に使うのなら 1000 BASE-T よりはよっぽど速いのでコストパフォーマンスが良いかもしれませんが,10 Gigabit ギリギリの速度が欲しいときには Atom だとダメそうですね。


というわけで簡単な計測とその結果でしたが,Xeon と Atom の二つの CPU の差がネットワークの速度にも大きく影響していることがよくわかる結果となりました。
ただし,ハードウェアオフローディングなどがよく効くハードウェアだとまた別の結果が出るかもしれないので,一概に CPU が常に帯域に影響するとは言えないと思いますが,少なくともタワー型のちょっとしたサーヴァーや家庭用 NAS なんかだと CPU の影響が結構効いてくるかもしれませんね。



宣伝:

この測定は私のアルバイト先である IIJ Innovation Institute(IIJ 技術研究所)で行ないました。IIJ-II では 100 GbE のネットワークに関する実験や高精度時刻同期,その他様々な実験・研究を行なっています。学生のアルバ…