Lyo.blog

最近のCPUには仮想化支援機能がついているので、ここ最近hyper-Vを使って遊んでいる。
windows11の上にまたwindows11を立てているが、なかなか軽快に動く。
windowsが完全におもちゃと化すので面白い感覚である。
（メモ：データを共有したい場合は拡張セッションを使ってUSBメモリのドライブを共有している）
ただ、仮想PC上では動画再生がカクカクだったので、流石にもう少しなんとかならんのか？と思い調べてみるとGPU-P（GPU パーティショニング）という方法で仮想PCとホストとでGPUを共有するやり方があり、試してみたのでその時のメモ。

参考元：Hyper-VでGPU(GPU-PV)を利用する方法 (Windows 10以降編)

環境
　前記事参照。
　※ここではRyzen 7 5700G（APU）を使って仮想PC上のwindows11からホスト(windows11)側のGPUを利用することを想定する。

事前準備
（１）BIOS設定
　①SVM mode を有効化（hyper-Vをやるなら最初に有効化すべき項目）
　②IOMMU を有効化
　私は②がauto設定になっていてハマった。明確にenableにする必要がある。
　（autoだとだめだった。また②がなくても仮想化自体はできるのでわかりにくい...。）

（２）host側でpowershellを管理者権限で実行
下記を実行する

Add-VMGpuPartitionAdapter -VMName "仮想PC名
Set-VMGpuPartitionAdapter -VMName "仮想PC名" -Passthru
Set-VM -GuestControlledCacheTypes $true -VMName "仮想PC名"
Set-VM -LowMemoryMappedIoSpace 1GB -VMName "仮想PC名"
Set-VM -HighMemoryMappedIoSpace 8GB -VMName "仮想PC名"

Remove-VMGpuPartitionAdapter -VMName "仮想PC名"

（３）仮想PC上にドライバをコピーする
下記のコマンドをpowershellで実行することでドライバの場所を探す。

Get-CimInstance -ClassName Win32_VideoController -Property * | Format-Table InstalledDisplayDrivers

ここまでやって仮想PC側を再起動する。問題なければタスクバーがGPUによって半透明化されるはず。
さらにデバイスマネージャーから問題が発生していないことを確認すればok。

とりあえず紙芝居ではなくなったのでまぁ満足。
一番のハマりドコロはBIOS設定の「②IOMMU を有効化」であった。autoだから使えると思いこんではいけない。

2年前ぐらいに新しいPCを買ったのだが、記録に残してなかった。前回構成から12年ぶりのリニューアルである。i7はだいぶ長いこと使えた。

当時の買い物ログ。
[ベアボーン]　ASRock AMD X300搭載 ベアボーンPC AMD Ryzen 4000シリーズ正式対応 DeskMini X300/B/BB/BOX/JP Mini ITX　¥25,000
[CPU] Ryzen 7 5700G ¥29,765 ->ポイント利用
[CPUクーラー]Noctua NH-L9A-AM4 Socket AM4専用、37mmロープロファイルのトップフロー型CPUクーラー(9010018000092)　¥7,073 ->ポイント利用
[メモリ]crucial　CT32G4SFD832A [SODIMM DDR4 PC4-25600 32GB]　¥11,330
[SSD] Western Digital ウエスタンデジタル 内蔵SSD 2TB WD Black SN770 ゲーム向け PCIe Gen4 M.2-2280 NVMe WDS200T3X0E-EC【国内正規代理店品】¥20,980
[その他]　アイネックス マグネットファンフィルター 120mm用 ホワイト CFF-120MGA-WH ¥1,837
計¥95,985
当時も円安で早めに買っておくべきだったと後悔していたが、26年1月現在で振り返ると、もう少し頑張って32GBモジュールをもう一つ買っておいてもよかったかもしれない。（26/1/8現在、￥23,803）

組み上げはtwilogに残している。
・https://twilog.togetter.com/Xyo/date-240119?tweets_order=desc
・https://twilog.togetter.com/Xyo/date-240121?tweets_order=desc
M.2インタフェースが新鮮な感じ。これまで組んだ中で最も小さなPCである。最近はもうこのサイズ感でいいんじゃないかと思うようになってきている。
性能は高まり（8コア）、利用する電力は更に抑えられている(idle:11w)のですごいことだ。

他、当時の構築メモ
2024/01/21
１Dataram RAMDisk
　-> Rドライブに未フォーマットで。
　　　その後NTFSにフォーマットしてフォルダきって保存。imgを圧縮。
(もっと早いソフトあるみたいだけどまぁいいか...。)
2 chrome
旧PCでパスワードをgoogleアカウントに保存。
　ブックマークをエクスポート

　新PCでパスワード同期化。
　ブックマークのインポート
　ニコニコ動画の履歴のサルベージー>ポータブル版の118版でデータをサルベージ（119から動かなくなる）

　ユーザプロファイルの移動はしなくなった。

３　USキーボードのAXキー化
　→レジストリをいじる方法ではなく、msのpowertoysを入れて対応

４　CrystalDiskInfoいれた。
新しい環境になる度にPCの移動が楽になってきていると感じる。昔の移行時間は何だったのか。

結論：対応しているCPUならば問題なく使える。

先日、JJUG CCC 2025 Fallに参加し、「native のその先へ！System.currentTimeMillis() の実装を見てみよう！ / YujiSoftware」のセッションを聴講した。個人的にnativeメソッドの先はあまり考えたことがなく、興味深いテーマだったからだ。currentTimeMillis()の内容を追っていくとJVMのソースに定義が書かれており、openJDK実装ならば、OSによって呼び出すシステムコールが変わる。最終的にはアランブラのRDTSC命令にたどり着くというもの。

RDTSC命令は学生の頃に触れたこともあり（何？19年前？）、やっぱりアレになるのか...。と懐かしく思ったのだが、RDTSC命令は発行時のクロック数を取得するものであり、最近のCPUでは当たり前のようにあるクロック周波数が可変するようなケースではうまく動かないのでは？という疑問が湧き、（実際Athlon64では可変の影響を受けたようで、過去の記事でも言及している。）どうやっているのか気になったので調べてみた。

・CPUクロックに基づく相対時刻の計測
　ここの解説が一番わかりやすい。
　リンク先の言葉を借りると、CPUの動作クロック毎に積算されるカウンタ（TSC）には以下の3タイプがある
　　①CPUの動作クロック毎に積算されるTSC
　　②CPUの動作クロックが変動してもカウンタ積算間隔は一定となる補償機能を追加したConstant TSC
　　③ACPIのP/C/T状態すべてにおいてカウンタ積算間隔が一定で動作する補償機能を追加したInvariant TSC
　で、②③ならクロック数が変動しても使えるということだ。
　※out-of-orderの影響を受けないRDTSCP命令があるというのもここで知った。

・タイマーカウンタ その３
　TSCがIntelとAMDでどの世代から切り替わったのか調べている記事。
　当時自分がAthlon64(K8世代)のTSCは①のTSCで、やはりクロックが可変すると影響を受けていたようだ。その後しばらくしてConstant TSC、Invariant TSC対応のCPUが出ている。2010年代前半には題意の疑問は解消されていたのだな。

と、ここまで調べて同僚と本件を会話したら、Armはどうなのか？と言われた。
調べてみるとArmではRDTSC命令自体が無いようである。アセンブラの世界にまで降りると移植性はなくなるのだな。

おまけ
　・マルウェアによるRDTSC命令の利用
　マルウェアがどのようにRDTSC命令を使うのか？という記事。クロックサイクル数、時間の経過の観測によってプログラムの存在する宇宙の状態（VMの中かどうか）を観測するような...天文学っぽい感じを受けて興味深い。

携帯電話を買い替えた。約17年ぶりである。
他の人に言うと割とビックリされるが、幸いスマホがないと大変という生活ではなく、電話＋メール専用機として使っていたらこんなに経ってしまったという感覚である。あわよくばバッテリーがヘタれるまでは...と考えていたが、手持ちのP705iμは第三世代携帯電話 (FOMA) 端末であり、2026年3月末に「FOMA」および「iモード」がサービス終了となるため、致し方がない。（電話の度にサービス終了予告のアナウンスが入るようになったのも使い心地が悪かった。）

春先からしばらく携帯ショップに行って最近の端末を見ていたが、どうも小さいもの好きの自分としては惹かれる端末はほとんどなく、どれも端末が大きく、重くなりそうで嫌だなと思ってた。MNPもあるし、もはやドコモにこだわらなくてもよいかと考えて色々探してたらIIJの乗り換えキャンペーンで紹介されていたjelly starが良さそうだったので、こちらにした。（ガラケースタイルを維持するという選択肢もあったが、やはりP705iμと比べると今のガラケーはどれもデカい作りになっていて魅力を感じなかった。）

P705iμと並べるとjelly starの方がやや短いが、圧倒的に分厚い。だが重さはあまり変わらない感覚だ。

重ねてみると横はほぼ同サイズ。

セットアップの様子。こんなに画面が小さいと文字を打つのが大変そうだと思ったが、ちゃんと打てる。

使い始めたばかりなので、使用感が分かるのは今後になる。現時点での感想はというと、jelly starは最初から液晶の保護シールが本体に付いているのが素晴らしい！大抵新しいデバイスを買ってもこの保護シートを貼るという作業がつきもので、その度に気泡が入らないかという心配をして億劫になりがちなので、最初から貼ってあるというのは大変ありがたい。

開通手続き後、十分程度で圏外になったP705iμ。もはや電話はできなくなったが、買ったときの様子と比較すると約17年の風格がある。これはこれで記念に残しておくかな。

しばらくは駅の近くで車を必要としない生活をしていたのだが、娘が誕生し早3年、
足となる車があるとやはり便利だなと思うようになり、最近車を購入した。

購入したのは中古のパジェロミニなのだが、せめてハンドルぐらいは新品気分を味わいたいと思って
純正品オプションのハンドルカバーを購入。2012年に終売となった車種のハンドルカバーを付ける記録なんぞ、あまり役に立たないと思うが残しておこうと思う。

説明書通り、最初に赤い糸を3つに切って準備。中性洗剤を含ませた雑巾でハンドルを拭いたら意外と汚かった。
ハンドルを180度回転させ、早速位置合わせ。

ハンドルを元に戻して縫い始める。今見ると5,6手あたりでミスっている...。

はじめの方こそもたついていたが、1/4超えたあたりからスピードアップ。半周完了。この日は曇りだったので、まだ暑くはなく作業しすやすかったのだが、西日が照らし始めて暑かったのを覚えている。

残り、半周の半分。ご丁寧にぐるっと反時計回りで縫う形になったが、説明書のアドバイスにあるようにここのアングル固定でハンドルを回しながらやったほうがラクである。（穴の位置が確認しやすい。）

ぐるっと回って完了の図。2時時間20分ほどかかった。

裁縫という経験は30年ぶりぐらいであろうか。
なかなか懐かしい体験だった。
この日は付けた後の試運転をしてみたが、なかなかハンドルが握りやすくなって良い感じである。