Index: /trunk/Commentary/kernelvm/20130413.log
===================================================================
--- /trunk/Commentary/kernelvm/20130413.log	(revision 209)
+++ /trunk/Commentary/kernelvm/20130413.log	(revision 210)
@@ -486,2 +486,343 @@
 		vt-d, vhost, 割り込み仮想化、など
 
+@katsyoshi
+ZFSでNASやってはまったこと
+	FreeBSD+ZFSでファイルサーバ
+		ZFS root/ ZFS + Samba
+		ZFSの内部構造とかはしない
+	ZFSとは
+		Sunが開発した次世代ファイルシステム
+		128bitアドレッシング
+		RAID5, RAID6, Triple Parity
+		重複排除
+		暗号化
+	とりあえず動くOS
+		Solaris
+		FreeBSD 7.0-
+		Linux Native/FUSE
+	ZFS Root壊れたサーバ
+		Memory 512MB * 4 -> 足りない
+	運用中のサーバ
+		2GB * 4 -> 原因不明で停止したことがある
+	メモリ足りない場合は
+		loader.confに設定してメモリを節約する
+		それでも落ちる時は落ちる
+		16GB/32GBくらいは欲しい
+	wiki.freebsd.org/RootOnZFS
+		構成する全てのdiskにルートパーティションを入れておくと、後で楽
+	ディスクが壊れたら
+		zfs replace old-disk new-disk
+		後は寝て待つ
+
+@d_kami
+自作x86エミュレータの終焉
+	何が終わるのか
+		x86エミュレータ
+	何が学べたのか
+		x86の命令セット
+		世の中にはOSがたくさんある
+	命令セットを覚えると？
+		ソースコードを紛失した、仕方ないので続きはバイナリで作ろう
+		バイナリエディタならあるぞ
+		ソースコードは残したくない、バイナリで書くしかない
+	つまり
+		役に立たない
+	どこではまるのか
+		同じような命令を作っていて、ちょっとした違いにはまる
+			命令長
+		条件分岐に失敗して無限ループ
+		Intelのマニュアルに騙される
+	3年間で10000行くらい
+	バグが多すぎる
+		勘違い、Intelの罠
+	もうやめます
+		それじゃあいつやめるのか、今でしょ
+	いきなりx86はやめるべき
+	作る前に調べるべき
+
+@boronology
+CD/DVDのエラー計測
+	DVD -> プリンタブルの糊でメディア同士がくっついてしまう
+	今回扱う内容
+		読み込みエラーの計測
+		ハードウェア的なエラーはまた今度
+	SANYOチップのPlextorドライブがBEST
+	前提
+		ECCというブロックの連続
+		182*208の2次元配列
+	20万行くらいエラーが出るのは普通
+	NGだと1600万くらいになったりする
+		色素を新規開発したのに、Media IDを使い回したせいで、おかしなことになった
+	経年劣化
+		あまり変わらない(5年)
+	DVD焼く時に埃が付いていると、その部分だけエラーの山になるが、特に問題はない
+		規格的には許容される
+	多くのドライブは、書き込み中に速度を落として様子をみたりしている
+	DVDなら三菱化学メディアの8倍速
+	CDなら太陽誘電
+	そんなことよりバックアップ多重化したほうがいい
+	プレス版のDVD-ROMでも10万くらいエラーは出る
+	TDKの超硬は5年保存でも4万くらいだった
+
+@sirrow
+EMC Style 2013 の解説
+	EMCという会社
+	EMC Style 2013
+		EMCによるGangnam Styleのパロディ
+		2013/01に公開
+	で、何が言いたいの？
+		Now everybody scale out down the row!
+		2013 -> 来年は違う？
+		スケールアウトが大切だ、というのは今だけ？
+
+@Talos208
+フォントとカーネル／VMのあやしい関係
+	フォントって何？
+		文字をデバイスに表示する時に表示するデータ
+		文字コードとグリフの対応表
+		一対一対応とは限らない
+			縦書きと横書き
+			合字
+		グリフ
+			図形としての文字
+	本来アプリケーション層のもののはず
+	CFFのフォントに脆弱性があってJailbreakとか
+		CFFの「命令コード」
+	OpenTypeフォント
+		AdobeとMicrosoftが策定したフォント形式
+		基本的にはTrueType、内部テーブルの種類が追加されている
+	CFFテーブル
+		CFFフォントが丸ごと入っている
+		他のテーブルと情報が重複している
+		PDFにCFFグリフのOpenTypeを埋め込むと、CFFの部分だけ使われたりする
+	CFFフォントの構造
+	CharaStringINDEX
+		.notdefCharString, A CharString
+	CharString命令表
+		callsubr
+		return
+		escape
+		dup
+		each index rollといった命令
+		まっとうな2スタックのスタックマシン
+		もうVMだよね
+	VM相当とはいえかなり制限されている
+		メモリアクセス、IO操作などは出来ない
+	Windows OSごと落ちるフォントを作ろうとしたが、詳細を忘れてしまって、次の機会
+
+@hktechno
+自作コンピューターでなんかする(仮)
+	発表をFPGAボードで行います！
+	ハードウェア担当は@cpu_labs
+	自作コンピュータ != 自作PC
+		命令セット
+		MMU
+		IOコントローラ
+		全部作る
+	mist32アーキテクチャ
+		アウトオブオーダー実行
+		独自の命令セット
+		ハードウェアとソフトウェアの強調動作
+	MIST1032ISA / MIST1032SA
+	ソフトウェア
+		gccはやめた方が良い -> llvm
+		binutilsは仕方ない
+	mrubyを載せたい
+	UART(シリアル)ついてる
+	とりあえずコンパイル出来れば動くらしい
+	これから
+		Out of Orderコアを動かす
+		MMUや割り込み・IO周りのテスト
+		ベンチマークを取る
+		SDカード対応
+		DMA対応
+
+@mhiramat
+Intel SDMのopcode mapから作るディスアセンブラ in kernel
+	kprobes/ftrace/perftoolsとかのメンテナの一人
+	# cat debug/x86/disassembly
+		現在走っているカーネルのメモリを指定した関数名でダンプして、逆アセンブルする
+	背景
+		kprobesのデバッグ -> 自己書換コードの様子が知りたい
+		簡単にメモリ上のバイナリをデコードしたい
+		既存のものはどれもオレオレフォーマットで出力するものばかり
+	SDMのAppendix A
+		Opcode Map
+		Intel Officialなinstructionのエンコード表記
+		-> arch/x86/lib/x86-opcode-map.txt
+	実装したもの
+		x86命令デコーダ
+			x64, AVXにも対応
+			Intel形式と、AT&T形式の両対応
+			debugfs, kdb, toolsの三つの使い方が可能
+		Kconfig
+			CONFIG_X86_DISASSEMBLE
+	Oopsでcodeの欄が既にdisassemble済で出てくる
+
+@naota344
+野良ビルドからみたGentoo
+	build process
+		unpack
+		patch
+		./configure
+		make
+		(make test)
+		make install
+	unpack
+		特に注目するようなところはない
+		Gentooにはunpackというコマンドが用意されている
+	./configure
+		econfを打つだけで、様々なオプションをつけてconfigureしてくれる
+	--disable-dependency-tracking
+		automakeの機能であるコードの依存チェックを無効化する
+	--disable-silent-rules
+		CC fooとかLD fooとかに省略されてしまうのを無効化
+		デバッグに不便なので
+	patch
+		/etc/portage/patches で管理される
+		パッチの紛失を防げる
+	makeの落とし穴
+		Makefileがおかしい
+			"cd hoge; make"とか書いてある
+			CFLAGS, LDFLAGSが反映されない
+			gccを直接読んでいる
+			リンクがおかしい
+		こっそり出ているエラー
+			command not found
+			file does not exist
+	make対策
+		ビルドログの監視
+		frecord-gcc-switches
+			.GCC.command.line section
+			CFLAGSなどのチェック
+		--hash-style=gnu
+		ld.goldを使う
+	build log監視
+		command not found以外にも
+		gccの警告
+	strict aliasing
+		int X; float *Y;
+		X = 1;
+		*Y = 3.14;
+		printf("%ld\n", X);
+	underlinking 1/2
+		--as-neededをつけるとリンクが通らなくなる
+	underlinking 2/2
+	make installの落とし穴
+		rootで実行される
+			突然 rm -r /usrされたり
+		インストールしたバイナリがやばいかも
+			RUNPATH, TEXTREL, EXECSTACKが変な値になっている
+			DT_NEEDED
+			SONAMEが抜けてる
+			world writableにsetuid
+			debug情報が付いたまま
+	他にも
+		容量がとても必要があるもの
+		/usrとか/varとかがあふれる
+		メモリ不足
+		gccのバージョン・カーネルの設定チェック
+	ブラウザでGentoo体験
+		bit.ly/9VG7xz
+
+@iorivur
+DragonFly BSD's Hypervisor vkernel
+	What's DragonFly BSD
+		HAMMER file system
+		だけじゃない！
+	vkernelのはなし
+		カーネルをユーザランドで動かす機構
+		カーネルのデバッグが主眼
+	make pkg-create
+		git gc --agressiveが後ろで走って壊れる
+	vkernel専用のカーネルをmakeする必要がある
+	make worldなどなど
+	ホストからは一つのプロセスに見える
+		通常のプロセスと同じように、gdbでアタッチしてbreakpointとか設置出来る
+	valgrindが動くと嬉しい
+
+@syuu1228
+MMIO ON VT-X
+	エミュレーションの種類
+		ゲストOSの全命令をソフトウェアエミュレーション -> 遅い
+		vt-x以前: 実行されると困る命令だけを動的に置き換えて、ネイティブに実行
+			Binary Translation
+		vt-x後: CPUをゲストモードへ切り替え、ゲストOSのプログラムをネイティブに実行
+			置き換える必要がない
+	本来は、ハイパーバイザーはCPU命令の置き換えはしないはずなのに……？
+		命令エミュレーションをしている部分がある！
+	VT-xなハイパーバイザーのライフサイクル
+		ホストOSのカーネルからゲストモードへ (VMEntry)
+		ハードウェアへのアクセスなど、ハイパーバイザーの介入が必要になったら、ゲストモードを停止し、ホストOSへ戻る (VMExit)
+		終わったら再開する
+	IO命令によるVMExit
+		Exit Qualification
+		アクセスサイズ
+		In/Outの方向
+		String命令か？
+		REP prefix
+		etc...
+	Exit Qualificationの情報に用いてIO命令をエミュレーション出来る
+		Exit Qualificationを見ればどうすればいいか分かる
+	MMIOによるVMExit
+		MMIOは通常のメモリアクセスと同じ命令を用いる
+		IO命令と違って命令で判別してVMExit出来ない
+		アクセスしたアドレスで判別可能
+		MMIO領域に相当するページにアクセスした時にVMExit(EPT violation)が起きるようにEPTを設定
+			read/writeともに拒否
+	MMIOでのVMExit時に得られる情報
+		どの種類のアクセス権違反か
+		ページに設定された権限
+		ゲストOSがアクセスしたアドレス(論理・物理)
+		アクセスがread/writeどちらかは分かる
+		書き込み元・読み込み先の情報(アドレス・レジスタ)と、アクセス幅が分からない
+		どんな命令が実行されたのか分からない
+		メモリアクセスする命令はx86だとかなりある
+	情報が足りない状態でMMIOするには
+		ゲストEIPの指すアドレスの命令をデコードして、opcode/oprandを取得
+		オペコード通りの動作をエミュレーション
+	これって命令エミュレーション！
+	なんでこうなっているのか
+		x86にはメモリアクセスする命令がとても多い
+		そもそもEPT violationはページのアクセス権限エラーを知らせるVMExitであって、MMIOを知らせるものではない
+	頻繁にMMIOされるとパフォーマンス的に不利
+		Local APIC仮想化支援
+			Local APICは割り込み周りで頻繁にアクセスされるが、MMIOを使っており準仮想化にもなじみづらいデバイス
+		この領域のMMIOだけはVT-xが特別扱いされている
+		レジスタ・条件によってはVMExit自体省略
+	Coaleseed MMIO
+		MMIO領域には、読み書きによる副作用が無く、単純なメモリの読み書きに置き換えられる部分が存在
+		VGAボードのピクセルデータの領域とか
+		VMExitしたらカーネル内で命令エミュレーションを実行、メモリ読み書き
+		ユーザランドでのデバイスエミュレーションを省略
+		e1000のパフォーマンスが9.7%向上
+	まとめ
+		ハードウェア仮想化支援機構であっても、全部やってくれるわけではない
+		出来ない部分はソフトウェアでやらないといけない
+	
+	Q/A
+		Exit Qualificationで得られるアドレスは実は正確ではない
+		例えば、ページフォルトの例では、境界をまたいでアクセスした際に、
+		実際にアクセスを開始したアドレスではなくて、禁止されているアドレスのみが
+		渡されるので、それを使ってエミュレーションするのは危険
+
+@yogata
+TELNETの話
+	telnet
+		ネットワークエンジニアの基本コマンド
+	「telnetも知らないんですかー？」
+	TELNETは暗号化出来る(結論)
+	TELNETとは？
+	RFC854
+		Network Virtual Terminalを作ること
+			コードセットは7bit USASCII, 標準制御機構
+		セッション確立時にオプション交換をする
+		ターミナルとプロセスで表示内容を同期させること
+	TELNETネゴシエーション
+	もしかしてネゴシエーションで暗号化出来るのでは？
+		RFC2946で定義されている
+		TELNETコマンドコード 38
+	TELNETのキャプチャを見る
+	結論
+		TELNETでも暗号化出来る
+	telnetはソースルーティングするパケットを作れる
