FPGA開発日記

カテゴリ別記事インデックス https://msyksphinz.github.io/github_pages , English Version https://fpgadevdiary.hatenadiary.com/

RISC-V ハイパーバイザー拡張の勉強 (hgatp, vsstatus)

5.2.9 ハイパーバイザーゲストアドレス変換および保護レジスタ (hgatp)

htatapレジスタはHSXLENビットの読み書き可能なレジスタであり、HSXLEN=32の場合のビットフォーマットを図5.18に、HSXLEN=64の場合のビットフォーマットを図5.19に示す。このレジスタはゲスト仮想アドレス変換の2番目のステージであるGステージアドレス変換の制御及び保護を行う(5.5節を参照のこと)。satpCSRレジスタと同様に、このレジスタはゲスト物理ルートページテーブルの物理ページ番号(PPN)、仮想マシン毎のアドレス変換を区別するための仮想マシン識別番号(VMID)、下種て物理アドレスの変換方法を選択するためのMODEフィールドから構成されている。mstatus.TVM=1の場合、HSモードでのhgatpレジスタを読み書きしようとすると命令例外が発生する。

f:id:msyksphinz:20210213224333p:plain
図5.18:RV32ハイパーバイザーゲストアドレス変換および保護レジスタ hgatp
f:id:msyksphinz:20210213224352p:plain
図5.19:RV64ハイパーバイザーゲストアドレス変換および保護レジスタ。MODE=Bare, Sv39x4, Sv48x4

表5.3はRV32とRV64におけるMODEフィールドのエンコーディングを示している。MODE=Bareでは、ゲスト物理アドレスはスーパーバイザー物理アドレスと同一であり、3.6節で示すようにゲスト仮想マシンと物理メモリ保護については追加的な保護は存在しない。この場合には、hgatpのほかのフィールドはゼロに設定していなければならない。

RV32では、MODEの有効な設定はSv32x4のみである。このモードでは通常のSv32ページ仮想メモリ方式を修正したもので、34ビットゲスト物理アドレスをサポートするために拡張したものである。RV64ではSv39x4およびSv48x4が定義されており、これはSv39およびSv49ページ仮想メモリ方式を修正したものである。これらのすべてのページ仮想メモリ方式については5.5.1節で説明している。RV64でさらに追加されている方式としてSv57x4が定義されており、これは仕様書の今後のバージョンで定義される予定である。

RV64におけるMODEフィールドの他の値については将来のために予約されており、hgatpの他のフィールドの異なる解釈のために使用される予定である。

f:id:msyksphinz:20210213224411p:plain
表5.3:hgatp MODEフィールドのエンコーディング

RV64の実装では、すべてのRV64 MODE設定をサポートする必要はない。

hgatpにおけるサポートされないMODEの書き込みは、satpのように無視されない。その代わり、hgatpのフィールドはWARLフィールドであり、そのような書き込みが発生した場合は識別される。


メモ:WARLとは Write Any Value, Read Legal Value

一部の読み書きCSRフィールドは、一部のビットエンコーディングに対してのみ定義されていますが、読み出しの際には必ず適法な値を返すことを保証しながら、任意の値を書き込むことができます。CSRの書き込みに他の副作用がないと仮定して、サポートされている値の範囲を決定するには、希望の設定を書き込んでみて、その値が保持されているかどうかを確認するために読み出すことができます。これらの値は、レジスタの説明ではWARLと表示されています。

WARLフィールドへのサポートされていない値の書き込みで例外が発生することはありません。実装では、最後の書き込みが不正な値であった場合、WARLフィールドの読み出しで任意の正規の値を返すことができますが、返される正規の値は、不正に書き込まれた値とハートのアーキテクチャ状態に決定論的に依存します。


5.5.1節で説明しているように、ページ仮想メモリ方式(Sv32x4, Sv39x4, Sv48x4)では、ルートページテーブルは16kiBであり16KiB協会にアラインしていなければならない。これらのモードへは、hgatp内の物理ページ番号(PPN)フィールドの最下位2ビットは常にゼロが読みだされる。定義されているページ仮想メモリ方式のBareのどちらか、あるいは両方のみをサポートしている実装では、PPN[1:0]はゼロに固定していなければならない。

VIMDのビット数は定義されていないか、あるいはゼロである。VMIDの実装されているビット数のことをVMIDLENと定義されるが、これはVMIDフィールドのすべてのビットに1を書き込み、hgatpの当該ビットをリードバックすることで保持されている1の数を調査することで識別できる。VMIDは下位のビットから先に実装される:つまり、VMIDLEN>0であれば、VMID[VMIDLEN-1:0]が書き込み可能である。VMIDLENの最大値(これをVMIDMAXと呼ぶ)はSv32x4では7であり、Sv39x4およびSv48x4では14である。

hgatpページテーブルのアップデートと後続のGステージアドレス変換の順番を制約しているわけではない。新しい仮想マシンのゲスト物理ページテーブルが変更されると、hgatpへの書き込みを行う前にHFENCE.GVMA命令を実行する必要がある可能性がある(5.3.2節を参照のこと)。

5.2.10 仮想スーパーバイザーステータスレジスタ (vsstatus)

vsstatusレジスタはVSXLENビットの読み書き可能なレジスタであり、VS-Modeでのスーパーバイザーステータスsstatusである。図5.20にVSXLEN=32でのビットフォーマット、図5.21にVSXLEN=64でのビットフォーマットを示す。V=1の場合に、vsstatussstatusの代替の役目を担い、従ってsstatusを読み書きする命令はすべてvsstatusに置き換えられる。

f:id:msyksphinz:20210213224435p:plain
図5.20:RV32向け仮想スーパーバイザーステータスレジスタ(vsstatus)
f:id:msyksphinz:20210213224451p:plain
図5.21:RV64向け仮想スーパーバイザーステータスレジスタ(vsstatus)

UXLフィールドはVU-ModeでのXLEN値を制御しており、VS-ModeでのXLEN値(VSXLEN)とは異なる可能性がある。VSXLEN=32の場合、UXLフィールドは存在せず、VU-ModeでのXLEN=32である。VSXLEN=64の場合はUXLフィールドはWARLフィールドであり、16ページの表3.1におけるmisaレジスタにおけるMXLのエンコーディングと同様である。特に、実装によってはUXLを読み込み専用フィールドとし、hstatutsのVSXLフィールドをコピーすることで強制的にVU-ModeにおいてXLEN=VSXLENとすることもできる。

VSXLENが32よりも大きな値に変更されると、UXLは単一の値に制限されなくなり、新しいVSXLENよりも小さな最も大きなサポート可能な値に変更される。

V=1の場合、vsstatus.FSおよびHSレベルでのsstatus.FSが有効である。どちらかのフィールドが0(Off)である場合、浮動小数点命令を実行しようとすると命令違反例外が発生する。V=1の時、浮動小数点のステートを変更すると、どちらのフィールドも3(Dirty)に変更される。

ハイパーバイザーが拡張コンテキストステータスの恩恵を受けるためには、VSモードで動作するゲストOSから独立して維持されているHSレベルのsstatusにそれ自身のコピーを持たなければならない。拡張コンテキスト状態のバージョンは明らかにVSモード用のvsstatusに存在しなければならないが、VSレベルのソフトウェアがvsstatus.FSを任意に変更できることを考えると、ハイパーバイザーはこのバージョンが正しく維持されているかどうかに頼ることはできない。V=1の間、HSレベルのsstatus.FSが独立してアクティブでなく、ハードウェアによってvsstatus.FSと並行して維持されていない場合、ハイパーバイザーは、仮想マシン間でコンテキストを切り替える際に、常に保守的にすべての拡張ポイントの状態をスワップすることを余儀なくされることになる。

読み込み専用のSDおよびXSフィールドは拡張コンテキストの状態を示しており、VS-Modeでのみ参照することができる。例えばHSレベルのsstatus.FSvsstatus.SDに影響を与えない。

実装は、UBEをhstatus.VSBEの読み込み専用コピーとすることができる。

V=0の場合、vsstatusはマシンの動作に直接影響を与えないが、仮想マシンロードストア(HLV/HLVX/HSV)もしくはmstatusレジスタのMPRV機能は例外であり、V=1の時のようにロードストアを実行する際に使用される。