Re: [Xen-japanese] PCIデバイス制御の処理をpcibackで行う件について

[Shohei Fujiwara <fujiwara-sxa@xxxxxxxxxxxxxxx>]

酒井さん

> 藤原さん
> 
>   Xen-develでは、かなり議論されているようですが...
>   
>   素人兼便乗質問ですが、
> xend/pcibackは、Dom0
> ioemu(Xen用のqemu)は、StubDom
> に、現在あるのですよね。

その通りです。


> とすると
> FLR(Function Level Reset：注以下のURL参照)の
> http://journal.mycom.co.jp/articles/2006/03/21/idf/002.html
> 置き場所は、ioemuしかありえないと思います。

Guestの「走行」に関する処理はioemuで良いと考えています。

ですが、Guestの「起動・終了」のハイパーコールに関する処理は、
dom0のままでよいと考えています。

なぜなら、Guestの「起動・終了」に関する処理は、dom0がリブートする間、
待ってもよいと思うからです。


> とすると、1)の案では、xendからpcibackへの移動で結局Dom0依存は変わらず、
> 2)の案では、ioemuからpcibackに移るのでDom0依存のまま
> と同じ気がするのですが、

まず、誤解があるかも知れません。
そもそも２つの案は、二者択一の排他的なものではないです。

１つ目の案については、賛成です。
xen-develのスレ主であるIntel Cuiさん、Citrix Keirさんと、
この件について、過去に議論したことがあります。
その結果、pcibackでFLRするという話になっています。

そして、２つ目の案について、反対しています。
その理由は、前に書いたとおりです。
SPOFの観点から、ioemuからpcibackに処理を移すべきでないと考えているからです。

以上です。


> 何か勘違いしているのでしょうか？
> 
> 以上
> 
> 酒井
> 
> 
> 
> 
> Shohei Fujiwara <fujiwara-sxa@xxxxxxxxxxxxxxx> wrote:
> 
> > 藤原です。
> > 
> > xen-devel にて、PCIパススルーデバイスの管理・制御の機能を、
> > pcibackに移行すべきか、の議論が行われてます。
> > 
> > http://markmail.org/message/4c7jx27gnvx3ctkh
> > 
> > ここでは以下の二つの案が出ています。
> > この件に関して、ご意見のある方は、
> > xen-devel にて参加をお願いします。
> > 
> > 1) xendに現在実装されているFLR機能を、pcibackに移動する
> > 2) ioemu−pciback間で通信することにより、
> >    「PCIコンフィグ空間の仮想化」を、
> >    ioemuから削除しpcibackに統合する。
> > 
> > 
> >     ＊      ＊      ＊
> > 
> > 
> > 究極的には、dom0のSPOF(Single Point Of Failure)を回避、
> > すなわちdom0の影響を受けずに、HVM Guestの動作を継続できたらいいなと
> > 思ってます。
> > 
> > ところが、上記の2)の案のように、
> > dom0のpcibackに処理が移行してしまうと、
> > dom0の影響(例えばリブートなど)が、PCIパススルーデバイスに伝播します。
> > つまり、HVM Guestはdom0の影響を受けてしまいます。
> > 
> > 
> > 現状のdom0は、SPOFです。それをSPOF回避に近づけるために、
> > まずは、dom0で行われている処理を減らしたいです。
> > その観点からも、pcibackに処理を移すべきではないと思ってます。
> > 
> > 賛同される方、援護射撃お願いします（xen-develで）。
> > 
> > 
> 


_______________________________________________
Xen-japanese mailing list
Xen-japanese@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-japanese