HCL - MSI TRX40 Pro WiFi

BCSharp · November 9, 2024, 4:27am

This is a report of my successful installation of Qubes OS on a custom build desktop PC based on motherboard MSI TRX40 Pro WiFi.

I have trying to install Qubes OS on this PC already for several years, unsuccessfully up until now. It was a shame because the PC has excellent specs for running Qubes OS: 250 GB RAM, 48 hyperthreaded processors, large NVMe storage. Unfortunately, although the installation went always successfully, the freshly installed system would freeze the moment dom0 tried to start any other qube. Any time a new minor version of Qubes OS was released, I would give it a try.

Finally it turned out that Qubes 4.2.3 with the latest Linux kernel (6.11) works fine, right from the start, without any special tweaking required. Here are some of my observations and tweaks of the installation, for a potential benefit to anyone trying to install Qubes OS on a system based on the same motherboard. The HCL .yml report is at the end of this post.

Remarks

Settings in UEFI Firmware

Settings menu: Advanced

Windows OS Configuration:

Secure Boot → Disabled

Settings menu: Security

Trusted Computing:

Security Device Support: Enable
AMD fTPM switch: AMD CPU fTPM
TPM State: Enabled
Platform Hierarchy: Enabled
Storage Hierarchy: Enabled
Endorsement Hierarchy: Enabled
TPM2.0 UEFI Spec Version: TGC_2
Physical Presence Spec Version: 1.3

It is possible that Qubes OS works also with other settings — untested.

Overclocking menu (OC)

Other Setting: CPU Features (scroll to the bottom):

IOMMU: Enabled
SVM Mode: Enabled

Not sure: Global C-state control. Currently works with Auto.

USB

Since I intend to attach external USB portable storage devices, I opted for the creation of the sys-usb qube during installation. Since the system does not have PS/2 ports, and the keyboard/mouse are attached through USB, the installer preconfigured the system such that keyboard/mouse are being passed through from sys-usb to dom0. This is great since the system is usable right out of the box, but not ideal: sys-usb has a red security label and letting it controlling dom0 input is not acceptable in my case.

A typical way of handling such concerns on non-PS/2 systems is to dedicate one of the USB controllers to dom0 for use with input devices, while keeping the rest of the USB controllers in sys-usb for use with storage devices and what not. In this scenario, there are two questions to be answered:

Which USB controller should be assigned to dom0?
What configuration modification are necessary to perform the reassignmed without locking yourself out of system?

Selection of USB Controller for dom0

The motherboard has five onboard USB controllers, collectively providing 16 USB ports of various speeds, (from 480 Mbit/s to 20 Gbit/s). Two of those five controllers have the same PC address, and are differentiated only by the device function number. In the past (on Qubes OS R4.0) I encountered issues when I tried to assign different functions of the same device to different qubes. Doing so may possibly have also security implications.

Finally, I concluded that the optimal choice is to assign the controller with BDF 23:00.3 to dom0. This controller provides only two USB ports (albeit USB 3.0, a.k.a USB 3.2 Gen1, 5GBit/s), leaving still 14 ports within the sys-usb qube (including a bunch of the very fast ones). The chosen ports are labeled Connector 3 and Connector 4 - use Board Explored in the UEFI firmware to locate them (they are at the back).

Other functtions on the same device are:

Cryptographic Coprocessor, BDF 23:00.1, module ccp
High-Definition Audio Controller, BDF 23:00.4, module snd_hda_intel

Both functions logically belong to dom0, so the whole device can safely be assigned to dom0.

Reassigning Selected Device to dom0

Ideally, the Plymouth installer would allow to select devices destined for sys-usb during installation, similarly like it allows for customized SSD partition selection. Unfortunately, we are not there yet, currently it is all or nothing: either sys-usb is pre-created and contains all USB controllers, or no sys-usb. The installer has also checkboxes that allow to pre-cofigure sys-usb to pass all keyboard/mouse to dom0, which I diligently checked for the sake of a smooth installation, and which can be disabled afterwards.

Before start, plug the keyboard and mouse into the ports designated for dom0.
Open the file /etc/default/grub in dom0.
Check that the line GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX usbcore.authorized_default=0" is present (add it if not). This will blacklist all non-HID from accessing dom0 during boot. The keyboard has still to be accessible so that the LUKS passphrase can be typed in, so make sure that option rd.qubes.hide_all_usb is not present.
Add line GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX rd.qubes.dom0_usb=23:00.3 below.
Save and close the file.
Run the command sudo sudo grub2-mkconfig -o /boot/grub2/grub.cfg in dom0.
Reboot.

Finally, remove the USB controller that is dedicated to dom0 (23:00.3) from sys-usb (which controller is currently assigned to sys-usb is visible on page Devices of the Settings window for sys-usb). This may not be that simple, because the settings app will demand that the qube be shut down first but doing it will effectively immobilize the keyboard and the mouse. Another way of doing it is to:

Edit /var/lib/qubes/qubes.xml. Search for element <property name="name">sys-usb</property>, then below the containing element <properties> find element <devices class="pci">. Within that element, comment out (or delete) subelement <device id=23_00.3> (it may have other attributes and subelements as well, delete all of it).
Reboot. Merely restarting sys-usb is not sufficient.
After reboot, verify that the keyboard and mouse/trackball are directly connected to dom0 (rather than though sys-usb) by running qvm-pci | grep 'USB controller' (the controller at the designated BDF should not be attached to sys-usb) and qvm-usb (the keyboard mouse/trackball should not be visible in sys-usb).
Open Qubes Global Config (from the Qubes / Tools menu or from Qube Manager) and select tab USB Devices.
In section USB Input devices, disable all input devices for qube sys-usb.

In short, an ordeal. That’s why I wished Plymouth could do it automatically.

Audio

My system has two audio devices:

Onboard MSI USB Starship/Matisse controller, apparenly utilizing a Realtek audo chip and supported by kernel module snd_hda_intel, at BDF 23:00.4
NVidia GeForce RTX 4090 capable of sending audio over HDMI or DisplayPort, also supported by kernel module snd_hda_intel, at BDF 21:00.1

21:00.1 Audio device: NVIDIA Corporation AD102 High Definition Audio Controller (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device 5103
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel
--
23:00.4 Audio device: Advanced Micro Devices, Inc. [AMD] Starship/Matisse HD Audio Controller
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device cb60
	Kernel modules: snd_hda_intel

Both PCI devices are fully in dom0, where PipeWire server and sinks are located. And yet, audio over DP works right from the beginning, with no tweaks required, while audio over USB does not.

I have spent reasonable but not excessive efort to figure out how to get audio out through the onboard chipset, but to no avail. Not a big deal for me, since I don’t need it but still puzzling. The issue seems to be with ALSA not recognising the onboard “sound card”. Here is a (partial) output of alsa-info:

!!Soundcards recognised by ALSA
!!-----------------------------

 0 [NVidia         ]: HDA-Intel - HDA NVidia
                      HDA NVidia at 0xe1080000 irq 87


!!PCI Soundcards installed in the system
!!--------------------------------------

21:00.1 Audio device [0403]: NVIDIA Corporation AD102 High Definition Audio Controller [10de:22ba] (rev a1)
        Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:5103]
23:00.4 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse HD Audio Controller [1022:1487]
        Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:cb60]

The NVIDIA-bound sound card is accesible though sysfs as /sys/class/sound/card0.

I tried to “force” snd_hda_intel on both cards with the following module configurations:

/etc/modprobe.d/alsa-local.conf:

options snd_hda_intel index=0,1

and:

options snd slots=snd_hda_intel,snd_hda_intel

…but without success. As a side note, Ubuntu 24.04 Noble Numbat, bootstapped on the same system, sees and supports both cards without any tweaks required.

Attachments

Qubes-HCL-Micro_Star_International_Co___Ltd_-MS_7C60-20241022-162556

---
layout:
  'hcl'
type:
  'Desktop'
hvm:
  'yes'
iommu:
  'yes'
slat:
  'yes'
tpm:
  '2.0'
remap:
  'yes'
brand: |
  Micro-Star International Co., Ltd.
model: |
  MS-7C60
bios: |
  2.81
cpu: |
  AMD Ryzen Threadripper 3960X 24-Core Processor
cpu-short: |
  AMD Ryzen 3960X
chipset: |
  Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex [1022:1480]
chipset-short: |
  AMD] Starship/Matisse
gpu: |
  NVIDIA Corporation AD102 [GeForce RTX 4090] [10de:2684] (rev a1) (prog-if 00 [VGA controller])
gpu-short: |
  GeForce RTX 4090
network: |
  Intel Corporation I211 Gigabit Network Connection [8086:1539] (rev 03)
  Intel Corporation I211 Gigabit Network Connection [8086:1539] (rev 03)
memory: |
  262039
scsi: |
  WDC  WDS100T2B0A Rev: 20WD
usb: |
  5
certified:
  'no'
versions:
  - works:
      'yes'
    qubes: |
      R4.2.3
    xen: |
      4.17.5
    kernel: |
      6.11.2-1
    remark: |
      Motherboard brand name is MSI TRX40 Pro WiFi.
      AMD Starship USB 3.0 Host Controller at BDF 23:00.2 assigned to dom0 for keyboard/trackball connection (Connector 3 and Connector 4 as displayed by the UEFI firmware Board Explorer).
      Audio over HDMI/DP (NVidia) works out of the box.
      Audio over onboard Realtek chipset (USB Starship/Matisse) does not work.
    credit: |
      BCSharp
    link: |
      FIXLINK

Sven · November 10, 2024, 8:39pm