K17TK LockTscToCurrentP0

LockTscToCurrentP0 bitはBIOSやマザーボードメーカー提供のOCツールやRyozen Masterを使っていない環境では0に設定されているはずです、-ltオプション無しで動作するPCではHPETを使用しているかK17TK動作時点ですでに1に設定されていると思われます。

LockTscToCurrentP0についてちょっと気になる事象に出くわしたので念のため書いておきます。
以下は、あくまでも対処療法で対応したというお話で、技術的な根拠があるわけではありません。

まずは発生した事象から。
Linuxのkernelが4.10以降Ryzenに対応しているということなので、kernelのソースを見てみようと思い、ubuntuの最新版?が4.10を使っているということで64bit版をVirtualBoxのゲストとしてインストールしました。
しかし、なにやら動作が非常に遅い引っかかるで実用に耐えない、そこで、既存のゲストOSをいくつか起動してみると。
　Fedora 17 32bit 問題なし
　Windows7 32bit 問題なし
　Centos 6.6 32bit なにやらおかしい
　Centos 6.7 64bit ubuntuと同じ
こんな状況になりました、そこで、P0をデフォルトに戻してみると見事に問題なく動作します。
最初は、OC設定で動作が不安定になっているのかと考えたのですが、VM以外はなんの問題もなく動作します。
次にBIOSをF2からF4に上げてみましたが、これもなんの変化もなし・・・・。
ふと、LockTscToCurrentP0のことを思い出しました、このPCはK17TK以外でBIOSを含め一切のOC設定をしていません、したがって、LockTscToCurrentP0の値は0になっています(デバッグの時に確認しました)、Windows10(ホストOS)自体はいまだにHPETを使用しています。
そこで、K17TKを-ltオプション付で起動したところ、OCした状態でもすべてのゲストOSがなんの問題もなく動作するようになりました。
もし、同じような事象に遭遇した方がいればお試しください。