As for VT-x and VT-d, I don’t know if they have anything to do with the ME, but coreboot itself does not enable or disable them, this allows the software application itself to do it. I was researching that a couple of days ago, and you could maybe just enable it yourself by using the ‘wrmsr’ command if whatever VM application you’re using doesn’t do it on its own
@kakaroto Some further research indicates enabling VT-x and VT-d are two very different things. One can use msr-tools to read and write the VT-x settings.
To read the settings:
rdmsr 0x3a
Where a return of 5 indicated VT-x has been enabled. More here.
Modifying this setting manually is discouraged and is often done by software such as KVM or Xen. Qubes appears to successfully enable it.
VT-d is a different story. For VT-d to work, it seems the DMAR tables might need to be be passed by coreboot. Note that the motherboard itself must also support VT-d. Perhaps someone from Purism can verify if their motherboards support VT-d.
Reading though the below threads, it seems some chips require VT-d to be initialized. This may be the case with Skylake although I have not dug through the Skylake reference documentation to see if this is answered. Coreboot has added VT-d initialization on several chipsets such as Sandybridge, however Im not sure if this is being worked on for Skylake currently. From everything I’ve read, it seems that unlike VT-x, VT-d likely needs some help from coreboot to work. The first thread here seems the most relevant, although its easy to get confused when looking into this as it seems many tend to mix up what required for VT-x vs VT-d. What seems clear is that VT-x is often enabled via software, but VT-d requires a BIOS to VT-d related ACPI table to expose the VT-d capability of the platform
https://www.mail-archive.com/coreboot@coreboot.org/msg49420.html