技術者見習いの独り言

(gdb) set follow-fork-mode child

前回の記事 の通りこの度二代目サブマシンと相成ったガジェットを紹介する One Mix とは GPD Pocket の二匹目の泥鰌を狙うかの如く現われた，GPD 社同様中国は深圳の 深圳市壹号本科技有限公司 （One-Netbook 社）の製品である。 Microsoft Surface に似たタブレット製品 Vbook や Android スマートフォンを手がける Voyo の子会社か何かのようだ。ところで Voyo のほうは モバイルサイト じゃないページが表示できなくて大変不安である（追記・Vivaldi ではなく Firefox だと表示された）。 互動百科に詳しい情報がある 。 GPD で検索しても日本語窓口などが見つかる GPD 社こと 深圳市中软赢科技术有限公司 と違って，One-Netbook などと検索してもセール情報やクーポン情報を掲載する日本のガジェット系アフィリエイトブログしかひっかからない。壹号本と検索して初めて公式サイトに行き当たる。（2019 年春に正式に日本市場参入が決定し，株式会社テックワンが日本の公式代理店・窓口になったため，現在では OneMix や One-Netbook と検索すると日本版公式サイトが出るようになりました） One Mix は GPD Pocket と比較して 360 度画面が回転するため同じ 7-inch で似たような筐体，キーボード，タッチパネルといった構成ながらも 2-in-1 マシンとして使えるのが強みであったが，CPU 性能やストレージ性能は初代 GPD Pocket より心許無かった。 しかし二代目 One Mix はストレージとして FORESEE ブランドの NVMe SSD を積んでいるほか，CPU が Core m3-7Y30+Intel UHD Graphics 615 となりかなり進化し，初代で計画されていた指紋認証まで付いている。 さらにその直後出てきた One Mix 2s は CPU が Core m3-8100Y にアップグレードされている。 GPD Pocket で WSL を使ったり論文を読んだりするのに使っていた関係上 2-in-1 で使えるのと SSD で使えるのは嬉しい。しかも Geekbuying でセールをずっとやっておりおおむね $669 で購

もう一年半経過してしまったのだが，2017 年の夏にちょっとした伝で総火演の予行を見に行った。とんでもないピーカン晴れのなか，総火演の直前にヤフオク！で PENTAX K-5 を入手したりカメラ屋の中古で Tamron A17 レンズを入手したりし， こんな写真撮ったぞという自慢をする。 また，総火演の直前には IndieGoGo で funding（した人に相乗りさせてもらった）GPD Pocket が届いたばかりであった。 Atom と eMMC という部分がちょっと厳しさもあるものの，メモリ 8GB の威力はかなり強く，7-inch のマシンにしてはかなり優秀なサブマシンだった。 また，Windows 10 はプリインストールのフォトアプリで RAW 画像を閲覧，現像することが可能なため，帰り道のバスで撮影した写真をざっくりプレヴューすることができとてもよかった。 ちなみにこの二枚目の写真は，captain stag のキャンプチェアと，あとブランドを忘れたが Amazon で安かったキャンプ向けの折り畳みテーブルである。夏はヴェランダでこれと GPD Pocket と Kindle Paperwhite でのんびり読書したりコードや論文を読んだりちょっと文章書いたりなど，大変快適な環境を過ごすこととなった 以降一年と二ヶ月ほど大活躍してくれたものの，これは昨日お役御免となり他の人の手に渡った。 次の記事 では GPD Pocket の後釜について紹介したい

表題のとおり。 Twitter でうめいていたら色々 advice をもらいかけたのですが色々試した上でのアレなので現状をまとめようと思った preliminary ホスト環境は Intel P55 chipset と Core i7 860（Lynnfield，Nehalem な世代のアーキテクチャ）という今やかなり古くなってしまった環境 もともとメインの Windows 環境にしていたがいまは Desktop 用途には止めて server 用途送り。Gentoo/Linux が入ってる。 MSI GTX 1060 6G OC（ショートなやつ）を入手した QEMU/kvm で passthrough させれば UEFI 環境の上で Windows を boot させて遊べると思った libvirt 4.5.0-r1，QEMU 2.12.1，Linux 4.14.83-gentoo 経緯 まず Linux の kernel cmdline を次のようにした /vmlinuz-4.14.83-gentoo root=/dev/sda5 ro rootflags=subvol=root rootfstype=btrfs quiet console=null intel_iommu=on iommu=pt cgroup_enable=memory swapaccount=1 vfio-pci.ids=10de:1c03,10de:10f1,8086:3b56,8086:3b34 vfio_iommu_type1.allow_unsafe_interrupts=1 threadirqs default_hugepagesz=1G hugepagesz=1G hugepages=4 video=nvidiafb:off,vesa:off vfi-pci.ids で指定しているのは GPU，GPU audio，on-board audio，on-board USB hubである。iommu も有効化した。 また，kernel config で nvidiafb や vesafb，efifb は無効化してしまっているため framebuffer は誰も掴んでいない。 そもそもホストマシンが古いせいで BIOS としてしか起動できてないですが……。 次に，

この 記事 の続き 前回の記事では 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->exi

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-

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 の日本語サイトのドキュメントはちょくちょく古い情報があって更新されていないので，よくひっかかってしまう。

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 している箇所があるのでそこ

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)

そろそろ多くの環境が 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 カーネルで扱える時計のうち，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 をクロックソースとし

タイトル通りです。 Intel 82599ES 10-Gigabit SFI/SFP+ を搭載した二台のマシンを DA ケーブルで直結し，iperf3 で測定を行なってみました。 マシンの性能は次の通り。 Atom のマシン Xeon のマシン 搭載されているメモリ量，メモリ速度は同じ，NIC も同じ。 CPU の性能が大幅に異なります。 さて，それでは測定結果をみてみましょう。 まずは Atom が client（送信側），Xeon が server（受信側）の場合。 図 1. Atom を client，Xeon を server として iperf3 を 10 回行なった結果のグラフ。上から帯域， congestion windowのサイズ，リトライ回数。 上から帯域， congestion windowのサイズ，リトライ回数で，x 軸が時間軸です。帯域はほぼ 9.40 Gbits/sec 前後をキープしており，期待に近い結果が得られていると思います。リトライ回数は全てゼロ。 次に Xeon が client（送信側），Atom が server（受信側）の結果です。 図 2. Xeon を client，Atom を server として iperf3 を 10 回行なった結果のグラフ。上から帯域， congestion windowのサイズ，リトライ回数。 悲惨ですね。まず目に見えてリトライ回数が多いです。ワーストケースで 98 回もリトライしていました。また，congestion window のサイズも変化しまくり，約 1.2 MB にまでなる場合も。従って，帯域もラインレートからほど遠い 6.43 Gbits/sec を叩き出しています。おうちで宅内の LAN に使うのなら 1000 BASE-T よりはよっぽど速いのでコストパフォーマンスが良いかもしれませんが，10 Gigabit ギリギリの速度が欲しいときには Atom だとダメそうですね。 というわけで簡単な計測とその結果でしたが，Xeon と Atom の二つの CPU の差がネットワークの速度にも大きく影響していることがよくわかる結果となりました。 ただし，ハードウェアオフローディングなどがよく効くハードウェアだとまた別の結果が出る