Xenのblktap

Xenのblktapのコードを、ちらと見る限り、ドライバー部分は、ioemuにかなり似ている。たとえば、blktapはいくつかのデバイスに対応している。そのコードは、tools/blktap/drivers/block-xxxxx.cのようである。これは、ioemuのやり方そっくりである。しかもqcow2rawがある時点で、かなり似ている印象をぬぐえない。さて、blktapの場合、tap_diskという構造体でつないでいる。最終的には、dtypes@tapdisk.hにつないで処理を行っている。
当然この手のDom0からDomUのドライバーを管理するアプリケーションは、XenStoreでDom0とDomUの通信を行っている。まず、Dom0からの通信は、tools/blktap/lib/の下の関数で行っている。DomU側は、blkfrontドライバーになる。なお、通信している情報は、sector, sector-size, infoの３つと、ring-ref, event-channelの2つ。余談だが、blkbackにもこのコードがある。これは、blkfrontが、blkbackとの通信を主眼に開発されたためである。blkfrontは、blktapとblkbackも通信できるというべきか？
また、page-refは、grant tableの値であり、event-channelは、event-channelの値である。これらの値は、blkfrontのtalk_to_backendで初期化され、Dom0のドライバに渡される。
Dom0のアプリケーションは、管理ツールであるxendが立ち上がると、blktapctrlが立ち上がる。そして、新たなディスクが必要となるたびに、tapdiskというプロセスが立ち上がる。このプロセスは、blktapctrlのblktapctrl_new_blkifで、起動している。なお、read/writeするデバイスは、/dev/xen/blktapctrlreadや/dev/xen/blktapctrlwriteになる。そして、この値は、tapdiskに引き継がれる。なお、blktapctrl側では、blkif->fds[]で管理されている。
そして、これらのアプリケーションは、Dom0側のドライバ(blktap)に対しては、ioctlで通信を行う。そして、DomU側のドライバ(blkfront)に対しては、xenstoreで通信を行う。
ついでに、blktapのコードの中に暗号関数AESのコードを見かけたので、何をしているか見てみたが、QCOWというQEMUのディスクフォーマットを扱うblock-qcow.cで使っているようであった。しかし、動かないようにしているので、実質使っていない。これもioemuと同じである。必要があれば、オンにすれば使えるようである。

ちなみに、blktapと同じようなゼロコピーを、SCSIのドライバーもやっているらしい。なお、Dom0/DomVTドライバー間の通信は、SCSI RDMA Protocol(SRP)らしい。こちらは、ソースコードを見た訳ではなくて、発表資料より。
Adminpanel