Qubes on Ryzen (AMD-Vi, AMD-V, RVI, TPM needed)

I plan to use Qubes OS (based on Xen Hypervisor) on the Framework 16 Laptop.

There have been many positive Reports for running Qubes on an Intel based Framework 13. (Hardware compatibility list (HCL) | Qubes OS)

Unfortunatly no one in the Qubes Community has tested it on an Ryzen 7 7480HS Architecture yet.

I would like to give it a try. But before I need to now if the Ryzen and the Framwork motherboard have the mentioned capabilities, else trying doesn’t really makes sense.

Strictly necessary for running Qubes is, that the CPU has following Features

  • AMD-Vi (also known as AMD IOMMU) to allow for PCI Passthrough
  • AMD-V (HVM) with
  • SLAT resp. RVI or NPT

and an separate TPM on the mainboard.

From the published AMD specs I can see the Ryzen 7 7480HS does support AMD-V and the PRO Modell (Ryzen 7 PRO 7480HS) does definitely support all the other Virtualization Features.

I’m just not sure that the non PRO Version used by Framework 16 has the necessary abilities.

Maybe somebody here (or working for Framework :smile: ) that already has an Ryzen 7 7480HS running Linux in front of him can find out directly

  • by issuing on the commandline
lscpu | egrep "Virtualization|Flags"` #or  
cat /proc/cpuinfo | egrep "Virtualization|Flags"

This might give necessary infos regarding AMD-V and SLAT. Lookout for

  • svm (AMD-V),
  • npt (SLAT or RVI),

Also interessting might be the flags (lbrv,svm_lock, nrip_save, tsc_scale, vmcb_clean, flushbyasid, decodeassists,pausefilter, pausefilter,pausefilter)

  • IOMMU (AMD-Vi) support on the other hand can be found by issuing
sudo dmesg | grep -i iommu

should print something like this if IOMMU is supported

iommu: Default domain type: Translated
iommu: DMA domain TLB invalidation policy: lazy mode

Help would be appreciated.

I found the info you’re after mate. I checked linux-hardware.org for AMD Ryzen 7 7840HS. It looks like AMD-V, SLAT/RVI, and AMD-Vi are supported. Here are the links for a deep dive:


That one is probably gonna be the main problem.

1 Like

Yeah. Depends if “separate TPM on the mainboard” means discrete TPM. Recent Ryzen machines have an fTPM in firmware.

I read the wording as explicitly not that one.

I can understand why. Could well be a “we’ve not tested it” scenario.

Quick look into the documentation says :
“TPM: Trusted Platform Module (TPM) with proper BIOS support (required for Anti Evil Maid)”

When you look at Anti Evil Maid :
“The current package requires a TPM 1.2 interface and a working Intel TXT engine.”

TXT support could be the sticking point.

Nah that thing barely works at all, no wonder qubes doesn’t want to use it.

1 Like

@x390 Thanks for pointing. That sounds very positive.

Looks like that bug only affects the linux random generator using the fTPM slowing down everything and they turned that off. For Hardware and Software attestation it should still work. … And its only important at the start of OS.
([PATCH 0/1] Avoid triggering an fTPM bug from kernel)

AMD is suggesting that a bios update might (have) fix(ed) it:

Yes it is - at least for now. Qubes AEM up until now only supports Intels TXT. But since TXT is Intel Tech you may not be able to expect it from an AMD anyway. Maybe a later version of Qubes supports AEM with AMD fTPMs.

Since everything else seems to be supported that’s at least not a showstopper for trying Qubes on the Framework 16 now.

Here’s your showstopper for Framework 16 with Qubes:
Touchpad detected, not working - User Support / Hardware Issues - Qubes OS Forum (qubes-os.org)

It also can’t wake from suspend, but I think it’s a similar root cause that interrupts aren’t being passed up properly.

Scanning through the CPU flags there, and I’m pleased to find that it supports AVX-512.
Probably won’t use it for anything except warming up the room, but I like the latest nifty stuff like that.
Maybe I’ll do a custom build of Blender with the compiler flags enabled and take it for a spin…