windows on ArchLinuxで無線フルトラする

この記事は Linux Advent Calendar 2020の13日目の記事です。
この記事を書いてる人はAdvent Calendar初参戦どころかQiitaに記事を書くのも初めてです。よろしくおねがいします。

2022/08/03追記

VRC公式のドキュメントにVM上で動かしたときにEACを回避する方法が掲載されました。運営的にはごく一部のユーザー向けで直接VM上のVRCはサポートしてないけれど動かす方法は調査したし掲載するね的なスタンスです。何にせよ、VM上での動作は下の追記で書いた利用規約には抵触していないと考えられるので、私が試して成功した方法を載せておきます。これは、私の環境では公式で書かれているCPUIDの偽装でVMが立ち上がらない&hyper-vのパススルーではVMは立ち上がるもののVRCにVM判定で弾かれたためです。

VM上でEACのVM判定を回避しつつVRChatを動作させる

どうもEACはマザボ情報を元にVM判定をしているようです。
KVMではこの情報を上書きできるのでこれを使っていきます。(macはこの方法を使えない)

1. ホスト側でsudo dmidecodeを実行する。
2. 以下の情報を控える
   • BIOS Informationより
     • Vendor
     • Version
     • Release Date
   • System Informationより
     • Manufacturer
     • Producct Name
     • Version
     • Serial Number
3. virt-managerのXML編集画面なりvirsh edit <VM name>で設定ファイルを開いて以下を追記
   • your infoは2.で表示された各項目の出力におきかえてください

<vcpu>...</vcpu>
<!--追記ココから-->
<sysinfo type='smbios'>
    <bios>
      <entry name='vendor'>your info</entry>
      <entry name='version'>your info</entry>
      <entry name='date'>your info</entry>
    </bios>
    <system>
      <entry name='manufacturer'>your info</entry>
      <entry name='product'>your info</entry>
      <entry name='version'>your info</entry>
      <entry name='serial'>your info</entry>
    </system>
 </sysinfo>
<os>
  ...
  <smbios mode='sysinfo'/>
</os>

1. powershellでmsinfo32を実行して表示される情報が3.で設定した情報と一致しているか確認する。

過去の追記

## 2022/07/29追記 KVMを用いて仮想化をしている場合には仮想環境上で実行する方法が存在します。(私の環境でも検証済み) しかし、VRChatがVM上での実行を許可していないこと、利用規約に以下の文言(セキュリティをバイパスするな)があることからBan対象になってもおかしくありません。ですので、具体的な方法について記載しません。 もし、VM上でVRCを実行したいという要望がありましたら[こちらのcanny](https://feedback.vrchat.com/open-beta/p/1212-please-dont-block-vms)に投票して、運営に正式に対応してもらったほうがいいと思います。

[利用規約より抜粋]
h. bypass any security or other features of the Platform designed to control how the Platform is used, harvest, or mine User Content from the Platform, or otherwise access or use the Platform in a manner inconsistent with individual human usage;

2022/07/26追記

2022/07/25更新のOpenBetaにて、VRChatはEasy-Anti-Cheat(以下EAC)を導入しました。26日現在、運営は仮想マシン上でEACを実行することを許可していないためこの方法は使えません。2. VMのconfigを編集するにある仮想マシンでないと偽装する方法を使うことで回避できた例があるようですが、環境に依存します。(ゲーミングノートではだめだった。)
EACの導入についての是非はここでは論じませんが、今後もVM上で実行したいという欲求があるならばこちらのcannyに投票することをおすすめします。もしかしたら、運営が対応するかもしれません。
また、Linuxでwindowsのプログラムを実行するProton上の実行は問題ないです。(手元で検証済み)
しかし、Proton上ではオーバーレイ系のソフトやOVR系のソフトは軒並み使えない+おそらく最も普及しているであろうQuest/Quest2はLinuxをネイティブにサポートしていないので、Apexなどと同じようにVMでの実行を許可してくれるとうれしいなぁというところです。

はじめに

私は今年7月からVRChatで生活しています。ヘッドマウントディスプレイ(以下HMD)はOculus Quest2を使用し、vive trackerで全身をトラッキングしてVRCの世界でも全身を動かせる環境を整えるほどにのめり込んでいます。
Oculus Quest/Quest2はOculus LinkやVirtual Desktopを使用することでPCリソースを使用するPCVR化が可能であり、より画質のいいVRC世界を見たり、PCのみの世界に行ったり、また前述のフルトラを実現することができます。
さて、そんな私ですが普段はArchLinux ＋ Qtileという環境を使用しておりwindowsとは全くの無縁です。日常作業に支障はありませんが、一点Quest/Quest2のPCVR化にはwindowsが絶対に必要です。しかし、私は過去ubuntuとデュアルブートをしたことで双方が破壊した経験があるため極力デュアルブートにしたくありません。でもVRCでフルトラしたいし、windowsは絶対必要。そんなにインスコしたくないなら仮想環境で隔離すればいいじゃないと思ったのでやっていきます。

ほぼポエム

## どう実現するのか KVMとQEMUと使用すとハードウェアレベルで仮想化が行われるためネイティブに近い仮想環境を得ることができます。また、Open Virtual Machine Firmware(OVMF)を使用することでPCIに刺さっているGPUを仮想環境上のOSにパススルーできるためグラフィックについてもネイティブと同程度の性能を得られます。 実際、私はこの環境でVRをしていますが特に問題があるとは感じていません。

どうして実機windowsを使わないのか

導入は結構めんどくさいのでデュアルブートでいいと思います。ストレージもネイティブレベルの性能を出そうとすると別途用意するほうがいいです(私は別ストレージ上に立てています)し、GPUも余分に必要、スタンバイ状態の消費電力は増えます。EACの制限にも引っかかりません。
複数台持つのはスペース的に厳しいとか、Linuxの操作性(タイリングWMとかターミナル操作)になれてしまってマウス操作を強要されるwindowsが嫌いとかも色々ありますが、私の場合ぶっちゃけ自己満足です。
異種のGPU持っててVMに割り当て直すのがやりやすいとか、いちいちキーボード切り替えるのめんどくさいとか、何もしてないのにクラッシュしやがる(実際はなんの操作が問題だったのかわかりにくい)こととかありますが、多分自己満足です。

前提条件

基本的にVRChatが快適にできるPC+$\alpha$くらいの性能で考えてください。最低限は動かせるレベルの最低限です。

項目	推奨	最低限
ホストOS 1	ArchLinux	x
ゲストOS 2	windows10	x
CPU	6C12T	4C4T(かなり厳しい)
RAM	32GB以上	12GB以上
GPU13	NVIDIA RTX2060S以上	NVIDIA GTX1060 6GB
GPU2(異種混合の場合)	intel iGPU or AMD Radeon	x
GPU2(NVIDIAのみの場合)	GeForce 600シリーズ以降	x
ストレージ	512GB以上	256GB以上
ネットワーク	有線+5gHz対応のルーター	PCも無線は遅延が大きくなる

• ネットワークドライバーはsystemd-networkdを使用します
• 私はNVIDIA+intel, NVIDIAx2の構成でしか試したことありませんのでNVIDIA+AMDは書きません
  (ドライバーの部分を読み替えれば動くとは思いますが)
• PCVR化するソフトはVirtual Desktopを使います。
  仮想環境上で使う関係でUSB接続のOculus Linkはかなり不安定です。
  VirtualDesktopは無線でQuest/Quest2と接続するためI/Oデバイス周りでネックになることはありません

GPUドライバーとXorgをインストールする

• NVIDIA+intel(第4世代まで)の場合

pacman -S xorg-server nvidia mesa vulkan-intel libva-intel-driver
yay -S prime-manager

• NVIDIA+intel(第5世代以降)の場合

pacman -S xorg-server nvidia mesa vulkan-intel intel-media-driver
yay -S prime-manager

• NVIDIAx2の場合

pacman -S xorg-server nvidia nvidia-utils

NVIDIAドライバーを有効化する

/etc/mkinitcpio.conf

...
MODULES=(nvidia nvidia_modeset nvidia_uvm nvidia_drm)
...

編集したら変更を反映する

root

mkinitcpio -P

仮想環境用のツールをインストールする

• iptablesを使用している場合

pacman -S qemu libvirt ovmf ebtables dnsmasq bridge-utils virt-manager

• nftablesを使ってる場合

pacman -S qemu libvirt ovmf iptables-nft dnsmasq bridge-utils virt-manager

IOMMUを有効にする

有効化したら一度再起動する

• Intel CPUの場合

/etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="... intel_iommu=on iommu=pt ..."

• AMD CPUの場合

/etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="... amd_iommu=on iommu=pt ..."

• 確認は以下のコマンドを叩いて何か出力されれば有効化されている

dmesg|grep -e DMAR -e IOMMU

IOMMUグループを確認する

PCIeスロットはCPU由来のものとPCH由来のものがあります。PCHはPCIeだけでなくUSBやSATAも管理しています。
そのため、PCH由来のGPUをパススルーしようとするとPCHが管理している他のデバイスも一緒にパススルーしなければなりません。
これはホスト側に影響が大きいため通常、隔離されているCPU由来のPCIeスロットに刺さっているGPUをパススルーします。
ここでは、IOMMUグループを表示してどのデバイスがどのグループで管理されているのかを調べ、隔離されているGPUを探します。
特にNVIDIAx2で構成されている場合は要確認です。

• シェルスクリプトを作成

checkgroup.sh

#!/usr/bin/env bash
shopt -s nullglob
for d in /sys/kernel/iommu_groups/*/devices/*; do 
    n=${d#*/iommu_groups/*}; n=${n%%/*}
    printf 'IOMMU Group %s ' "$n"
    lspci -nns "${d##*/}"
done;

• 実行

bash checkgroup.sh

• 出力の例
  IOMMU Group No PCIデバイスID デバイス区分: デバイスの詳細みたいな感じで出力されます。
  この中からGPUのみのIOMMUグループを探し、そのグループに存在するPCIデバイスIDを覚えておいてください。後で使います。

...
IOMMU Group 18 26:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2070 SUPER] [10de:1e84] (rev a1)
IOMMU Group 18 26:00.1 Audio device [0403]: NVIDIA Corporation TU104 HD Audio Controller [10de:10f8] (rev a1)
IOMMU Group 18 26:00.2 USB controller [0c03]: NVIDIA Corporation TU104 USB 3.1 Host Controller [10de:1ad8] (rev a1)
IOMMU Group 18 26:00.3 Serial bus controller [0c80]: NVIDIA Corporation TU104 USB Type-C UCSI Controller [10de:1ad9] (rev a1)
IOMMU Group 19 27:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function [1022:148a]
...

vfio-pciモジュールをロードする

GPUドライバーがロードされるより前にvfioがロードされる必要があるので下のように各種ドライバーよりも前に記載してください

/etc/mkinitcpio.conf

...
MODULES=(vfio_pci vfio vfio_iommu_type1 vfio_virqfd nvidia nvidia_modeset nvidia_uvm nvidia_drm)
...
HOOKS=(... modconf ...)
...

変更を反映

root

mkinitcpio -P

(NVIDIAx2構成のみ)GPUを分離するスクリプトの作成

archwikiでは/etc/modprove.d/以下にファイルを作成しPC起動時に対象のGPUを分離する手法が取られています。
しかしこれでは対象GPUは常に分離されるためホストPCで使用できなくなります。
分離自体はカーネルパラメータに記載することでできるので簡単なスクリプトを作成し、機会に応じて分離できるようにします。
ここではgrubを対象とし、スクリプトを実行するとgrubファイルを編集した後、grubを再構成します。

swichpci.sh

#! /usr/bin/env bash
GRUBFILE=/etc/default/grub
if [ ! $USER = root ]; then
    echo "Please run under root user"
    exit 1
fi

if [ $(cat $GRUBFILE | grep -w GRUB_CMDLINE_LINUX) = "GRUB_CMDLINE_LINUX=\"\"" ]; then
    echo -e "\033[0;31mLinux only to Shared VM\033[0;39m"
    sed -i -e "s/GRUB_CMDLINE_LINUX=\"\"/GRUB_CMDLINE_LINUX=\""上のIOMMUグループの確認したグループに所属する全てのPCIデバイスIDをカンマ区切りで記載する"\"/g" $GRUBFILE
else
    echo -e "\033[0;31mShared VM to Linux only\033[0;39m"
    sed -i -e "s/GRUB_CMDLINE_LINUX=\"vfio-pci.ids="上のIOMMUグループの確認したグループに所属する全てのPCIデバイスIDをカンマ区切りで記載する"\"/GRUB_CMDLINE_LINUX=\"\"/g" $GRUBFILE
fi
grub-mkconfig -o /boot/grub/grub.cfg
echo "Done!"

• 実行する
  to Linux onlyでホストPCにバインド、to Shared VMで対象GPUをホストPCから分離する(次回起動時)

root

bash ./switchpci.sh
> Shared VM to Linux only
  Generating grub configuration file ...
or
> Linux only to Shared VM
  Generating grub configuration file ...

(異種混合のみ)GPUの設定

iGPUと外部GPUが混在する場合、iGPUで画面出力するのか外部GPUで出力するのかの設定が必要です。
今回はoptimus-managerを使用しているため、起動時の初期状態はiGPUで画面出力をし、外部GPUは明示的に呼び出すHybridモードに設定します。

/etc/optimus-manager/optimus-manager.conf

...
startup_mode=hybrid
...

(異種混合のみ)GPUを動的に分離するスクリプトの作成

windowsのNVIDIAドライバーにはoptimusと呼ばれる内蔵GPUとNVIDIA GPUの両方を搭載するゲーミングPCの消費電力を低くするために使用するGPUを動的に変更する機能があります。
Linux向けのNVIDIAドライバーにも搭載されていますが動的な変更は公式にはサポートされていません。
しかしながら、ArchLinuxではAURリポジトリにあるprime-managerを使用することでセッションのログアウトのみでGPUを切り替えることができるようになります。
残念ながら私の環境ではXorgは正常に動くのですが、動画を再生しようとするとカクカクで見れないです。
解決策を知っていたらぜひ教えてください。

switchmode.sh

#! /usr/bin/env bash
if [ $(optimus-manager --status | grep next | awk '{print $NF}') = "intel" ]; then
    echo -e "\033[0;31mIntel to Hybrid\033[0;39m"
    optimus-manager --switch hybrid --no-confirm
else
    echo -e "\033[0;31mHybrid to Intel\033[0;39m"
    optimus-manager --switch intel --no-confirm
fi

• 実行する
  Hybrid to IntelでNVIDIA GPUがアンマウントされます。
  Intel to Hybridでマウントされます。

noroot

bash switchmode.sh
> Hybrid to Intel
or
> Intel to Hybrid

仮想ブリッジを作成する

virt-managerのデフォルトのネットワークではゲストOSから外部にアクセスはできますが外部からゲストOSにはアクセスできません。
そこで仮想ブリッジを作成することで外部へゲストOSを公開します。
ここではsystemd-networkdでの作成のみ紹介します。

• 仮想ブリッジの作成

/etc/systemd/network/br0.netdev

[NetDev]
Name=br0
Kind=bridge

• 仮想ブリッジのネットワーク設定

/etc/systemd/network/10-br0.network

[Match]
Name=br0
[Network]
DHCP=ipv4

• 物理NICを仮想ブリッジに接続する

/etc/systemd/networkd/20-wired.network

[Match]
Name=enp*
[Network]
Bridge=br0

仮想環境にwindowsをインストールする

ここまでの設定で疲弊していると思いますがいよいよwindowsをインストールしていきます。
ここではlibvirtのフロントエンドであるvirt-managerを使用します。
また、仮想環境上のwindowsの性能向上のためにvirtioを使用します。

windowsのインストールisoとvirtioのwindowsドライバーisoをダウンロードする

• windowsのインストールisoはここ
• virtioのwindowsドライバーはここのDirect downloads(stableでいいと思います)

virt-managerでwindows環境の作成

1.1 作成ウィザードに沿ってインストール作業を進める

前提条件に沿ってCPUは4コア以上(できれば総スレッドの半分)、RAMは8GB以上与えてください。
ステップ5で必ずCustomize configuration before installにチェックを入れてください

Customize configuration before installにチェック

1.2 仮想環境を調節する

前の項でFinishを押すと下の画像のような設定画面が開きます。
最終的に下の画像のようになればいいです。

設定するのは以下のとおりです。

• OverviewのChipsetをQ35、FirmwareをUEFIにする(OVMF_CODE.fdの方でいい)
• CPUsのTopologyのところのCoresを変更する(ウィザードのままだとSocketsに割り当てられwindowsが認識できない)
• NICのNetwork InterfaceをBridge deviceにしてDevice Nameを先に作成したbr0にする
• NICのDevice modelをvirtioに変更
• Disc 1のBus Typeをvirtioに変更
• Add HardwareからStorageを選択、Device typeをCDROMに変更しSelect..から先にダウンロードしたvirtioのwindowsドライバーisoを選択
  
  
  

2. windowsをインストールする

起動すると下のような画面が出てきますがここで"exit"と入力します。

BIOS画面が出てくるのでBoot ManagerからwindowsのインストールisoのCDを指定し、数回Enterを押すとwindowsのインストーラーが起動します。

カスタムを選択し

ドライバーの読み込みからwindows10のvirtioドライバーを選択します

すると、インストール場所にストレージが追加されているので選択して後はインストーラーの指示に従ってインストールを進めていきます。
このときネットワークに接続ができないと言われますが、接続しないを選択して続行してください。

3. windowsにvirtioのドライバーを当てる

設定->詳細情報->デバイスマネージャーのほかのデバイスにある全てのデバイスにvirtioドライバーをあてます。
対象デバイスを右クリック->ドライバーの更新->手動更新->virtioドライバーのCDを選択を繰り返します。
ドライバーが入るとネットワークに接続できるようになっているはずです。
設定からMicrosoftアカウントにログインしたらここで一旦VMをシャットダウンします。

VMにGPUをパススルーする

コンシューマ向けGPUは基本的に仮想化をサポートしていません。
そこでベンダーIDを偽装することでwindowsがパススルーされたGPUを認識できるようにします。

1. GPUがホストPCにバインドされていないか確認する

仮にホストPCにバインドされた状態でGPUパススルーしようとするとカーネルパニックが発生し、強制終了するしかなくなります。
必ず確認してください

• NVIDIAx2の場合: 先に作っておいたスクリプトを実行、再起動した後にnvidia-smiを実行して対象GPUが表示されていない
• 異種混合の場合: 先に作っておいたスクリプトを実行、セッションからログアウトした後に、nvidia-smiを実行してプロセスに何も表示されていない

2. VMのConfigを編集する

VMのOverview->XMLを選択して下のように追記していきます。

virt-manager

...
    <hyperv>
      ...
      <vendor_id state="on" value="0123756792CD"/>
    </hyperv>
...

3. VMにGPUをマウント

VMの設定からAdd Hardware->PCI Host Deviceで先に確認したGPUを選択してください。
GPU本体だけでなくGPUに付属してるオーディオコントローラーやUSBコントローラーを全てマウントしてください。
今回はSpiceを用いてUSBをゲストOSにマウントするためVideo QXLはそのままにしておいてください。

4. 仮想マシンのチューニング

• VMのタイマー管理
  • タイマー管理にhpetを使用する
  • rtx+pitではCPUが非常にボトルネックになる
  • 参考: High KVM/QEMU CPU utilization when Windows 10 guest is idle

  <!-- before: this config uses over 15% of a host CPU core -->
  <clock offset='localtime'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
    <timer name='hypervclock' present='yes'/>
  </clock>

  <!-- after: this config drops to about 3% of a host CPU core -->
  <clock offset='localtime'>
    <timer name='hpet' present='yes'/>
    <timer name='hypervclock' present='yes'/>
  </clock>

• CPU Tuning
  • VMが使用するCPUを固定する
  • 特にRyzenではCCX跨ぎの影響を軽減する
  • cpusetは使用するCPUによる
  • 参考: bryansteiner/gpu-passthrough-tutorial

<vcpu placement="static">12</vcpu>
<iothreads>1</iothreads>
<cputune>
    <vcpupin vcpu="0" cpuset="6"/>
    <vcpupin vcpu="1" cpuset="18"/>
    <vcpupin vcpu="2" cpuset="7"/>
    <vcpupin vcpu="3" cpuset="19"/>
    <vcpupin vcpu="4" cpuset="8"/>
    <vcpupin vcpu="5" cpuset="20"/>
    <vcpupin vcpu="6" cpuset="9"/>
    <vcpupin vcpu="7" cpuset="21"/>
    <vcpupin vcpu="8" cpuset="10"/>
    <vcpupin vcpu="9" cpuset="22"/>
    <vcpupin vcpu="10" cpuset="11"/>
    <vcpupin vcpu="11" cpuset="23"/>
    <emulatorpin cpuset="0-3"/>
    <iothreadpin iothread='1' cpuset='4-5,12-17'/>
</cputune>

パススルーの確認と入力デバイスのマウント

タスクマネージャーを開いてGPUの項目にパススルーしたGPUが表示されていればパススルーは成功です。
VMの操作は2通りあり、virt-managerの画面からマウスとキーボード操作する方法とホストの入力デバイスをリダイレクトでマウントする方法です。
後者はVMをシャットダウンするまでホストOSを操作できません。
USBリダイレクトはVMの設定->Virtual Machine->USB Redirectから可能です。

必要なソフトをダウンロードしてセットアップする

下記のソフトをインストールしてください。インストール方法は他を見てください。
(Linuxのパッケージ管理になれているならchocolateyがオススメです。)

• NVIDIA Driver
• Steam
• Oculus setup
• Virtual Desktop Streamer
• OpenVR-AdvancedSettings

[2021/9/24追記] パッチを当てなくても良くなりました

VirtualDesktopでSteamを実行するには別の作業が必要になります。 [ここ](https://tona.hatenablog.jp/entry/2020/09/21/205704)が詳しく解説してくれているので見てセットアップしてください。 VirtualDesktopにパッチを当てるのに必要な[sidequest](https://sidequestvr.com/)はクロスプラットフォームなのでArchLinuxでも以下でインストールすれば使えます。

yay -S sidequest-bin

また、仮想ブリッジを用いてVMを構築したためQuest/Quest2のVitualDesktopアプリからwindowsが見えているはずです。
もし見えていなかったらネットワーク周りを確認してください。

Vive Trackerとベースステーションを設定する

ここまで来たら後少しです!
設定の前にリダイレクトできるUSBの数を増やします。
VMの設定->Add HardwareからUSB Redirectorを選択します。最低5つあれば足ります。(トラッカー用ドングルx3+入力装置x2)
もしくはドングルを直接VMに追加してください。(Add Hardware->USB Host Device)

Vive Trackerとベースステーションのファームウェアを更新してSteamで使用できるように設定していきます。

1. ベースステーションとトラッカーとVMをペアリングする

ペアリングする前にトラッカーに付属のドングルを全てVMにリダイレクトしてください。
後はここに書いてある方法でペアリングができると思います。

2. ベースステーションのファームウェアを更新する

ここを参考にファームウェアを更新してください。
上記リンクの4の項目はホストOSにマウント->VMにUSBリダイレクトと読み替えてください。
(USBリダイレクトはVMの設定->Virtual Machine->USB Redirectから可能です。)

3. Vive Trackerのファームウェアを更新する

先に付属のドングルをVMにリダイレクトしてSteam上でトラッカーを認識させてください。
ファームウェアの更新が必要であればドングルのリダイレクトを解除してここ参考に更新してください。
上記リンクの4のUSBに接続はVMにUSBリダイレクトと読み替えてください。
また、この方法で更新をするとSteam上では「失敗しました」と表示されます。
しかし、再度ドングルをVMにリダイレクトしてトラッカーを接続すると正常に動作し、ファームウェアの更新も通知されません。
おそらく、更新はできているとは思いますが保証はできません。

VRChatにログインしてフルトラする

お疲れ様でした!
これで全ての作業は終了です。Virtual DesktopからVRChatを起動してSteam上でトラッカーが認識されていればフルトラッキングできるはずです。

おわりに

今回はVRを実行しかつフルトラッキングできる仮想環境windowsを作成してみました。
見ていただいた方はお分かりいただけたでしょうが作業量が半端じゃないです。
実際にはVMを作るだけでなく、後半に割愛したVirtual Desktopの設定やトラッカーの設定が作業量に追加されます。
いっそのことデュアルブートするか、もう一台VR専用のPCを買えばいいと思います。
本当に趣味の領域を超えないような気はしますが誰かが同じようなことをするときの参考になれば嬉しいです。

余談ですが、HTC viveやValve Indexだとオーバーレイアプリが使えないなどの制約はありますがフルトラも完全にLinux上でできるようです。(ソース)
SteamVR自体はクロスプラットフォームで有線のHMDは実質的にただの画面だからできる芸当です。
それでも、ケーブルレスな無線フルトラは快適ですし現状それが可能なのはQuest/Quest2のみなのが辛いところです...。

参考サイト

• QEMU
• libvirt
• OVMF による PCI パススルー
• Linux, AMD Ryzen 3900X, X570, NVIDIA GTX 1060, AMD 5700XT, Looking Glass, PCI Passthrough and Windows 10
• 【Linux Mint】【QEMU/KVM】KVMによる仮想化Win10へのGPUパススルー設定

Quest/Quest2でのフルトラで参考になりそうなサイト

• Oculus Questで無線フルトラをする - 簡易設定編
• Virtual Desktopを最適な設定にする - 各種設定について
• sidequest

1. Ubuntuでもできるようですが私がしたこと無いので取り上げません。prime-selectでできるとかなんとか。 ↩

2. 正規のライセンスを買ってください。 ↩

3. VRChatが快適にできるGPU条件です。ここは金銭が許す限り強いGPUを搭載してください。最近はRTX3070がオススメです。 ↩