vectorの#46をcpu#1に送る設定idtinitでIDTのロード(lidt)と設定。xv6の場合、Interruptの処理を任せるCPUは決め打ちにしている。linuxでは、もうちょっと洗練されて設定されてる。Interruptが発生した時、権限の確認をした上で、各種レジスタをpushする。number)から、IDTからそれに対応するentryがわかるので、callbackのアドレスに飛んで実行する。この流れを詳しめにみていく。eflag.IFがONである必要がある。以下の2~8はhardwareが自動的に行う処理IDTRからIDTの場所がわかるので、IDTのindexのidxを参照できる。権限に対応するssとespをロード。xv6の場合、4は原則当てはまる。register)と%esp0となる。codeもあったらそれもスタックにpusheflagsのIFをOFFに。[15:0])があるので、それぞれ%csと%eipにloadする。address)がvector_##iとなっているので、そちらの関数に飛んでソフトウェア的な(OS側の)処理が開始される。Interrupt発生直後のhardware(x86)の対応こちらは外部I/Oがinterruptを発生させるので、最初の部分がプログラム内で発生するExceptionよりもやや複雑。lineの状態)を受け取る。APICにsignalを伝達する。今回は振り分けるCPUは決め打ちなので、skip以下、Exceptionの場合と同じ。APICがどのCPUにInterruptを処理させるのかを決め、該当のCPUにお願いをするところが最初に挟まる。interruptが起こったときが該当。"forkretからinitまで"のところでだいたい確認している。Interruptを振り分けているところ。exit();Interrupt発生時のOS側の対応vector_##iが呼ばれ、trap()関数で、IRQ_TIMERの場合、IRQ_IDEの場合..とswitch文により振り分けられ、個別のinterruptの処理が走る。APICに伝えて、Interruptが終わる。Routine)を呼び出す。この呼び出し方複雑なので、次あたりにまとめたい。trap関数終了後のOS側の対応trap関数が終了した後は、trapasm.Sにて、stackをpopして、最後にiret命令を実行する。exceptionでhardwareが自動的にやったことの逆を行う。Exceptionsで詳しめの解説がある。landに引き戻されるということだ。%eipやら%ssやら%espは前の状態に戻る。ちなみに、linux2.6では、ret_from_intrおよび、ret_from_exceptionが同じ役割を担っている。