Basically, we are missing a DMAR table in the BIOS
How I came to the conclusion?
2013 Chromebook Pixel Link runs on Intel's HM75 chipset
2015 Chromebook Pixel Samus runs on Intel's HM97 chipset
Looking up the HM75 chipset specs on
http://ark.intel.com/#@Chipsets - links to http://ark.intel.com/products/64348
At a brief glance, Intel are telling us VT-d is not available on this chipset.
However, if we click on 'Link', next to Essentials -> Datasheet
Jump to page 282, we see the list of Intel® VT-d Features Supported
So we know the motherboard chipset of HM75 is VT-d compatible at a native level.
HM97 for mobile laptops is not listed on the website at present, but Wildcat Point chipsets of Z97 and H97 for Desktops are listed, and show the same wrong info of VT-d not available, at a quick glance, but further reading of the datasheet PDF indicates the opposite.
We know the CPU on Link & Samus is VT-d compatible.
To get VT-d to work, we need a compatible CPU, a compatible chipset and a flag in the BIOS. All 3 must be available, else we won't get VT-d.
It appears we have all the wiring in place (CPU & chipset), but no switch attached to the wires, to turn it on or off (BIOS)
The factory SeaBIOS does not turn off VT-x completely.
If we run a qemu 2.4.0-4 on Arch Linux 4.2.2-1, it gets turned on at run time,
Before we run qemu
$ rdmsr 0x3a 0
Whilst running qemu and after we finish / kill qemu
$ rdmsr 0x3a 5
So VT-x works fine. If we turn it on by running qemu, we should have access to VT-d, (theoretically speaking, if Google never turned off VT features in the SeaBIOS to begin with), but to no avail.
If I run
$ ls -l /sys/firmware/acpi/tables
total 0 -r-------- 1 root root 108 Oct 9 14:40 APIC -r-------- 1 root root 18208 Oct 9 14:40 DSDT drwxr-xr-x 2 root root 0 Oct 9 14:40 dynamic -r-------- 1 root root 244 Oct 9 14:40 FACP -r-------- 1 root root 64 Oct 9 14:40 FACS1 -r-------- 1 root root 64 Oct 9 14:40 FACS2 -r-------- 1 root root 56 Oct 9 14:40 HPET -r-------- 1 root root 60 Oct 9 14:40 MCFG -r-------- 1 root root 4088 Oct 9 14:40 SSDT
$ acpidump -s
ACPI: RSDP 0x00000000000F48E0 000024 (v02 CORE ) ACPI: RSDT 0x000000007CF44030 000038 (v01 CORE COREBOOT 00000000 CORE 00000000) ACPI: XSDT 0x000000007CF440E0 00004C (v01 CORE COREBOOT 00000000 CORE 00000000) ACPI: DSDT 0x000000007CF44250 004720 (v02 COREv4 COREBOOT 20110725 INTL 20130117) ACPI: FACS 0x000000007CF44210 000040 ACPI: FACP 0x000000007CF48970 0000F4 (v05 CORE COREBOOT 00000000 CORE 00000001) ACPI: HPET 0x000000007CF48A70 000038 (v01 CORE COREBOOT 00000000 CORE 00000000) ACPI: APIC 0x000000007CF48AB0 00006C (v01 CORE COREBOOT 00000000 CORE 00000000) ACPI: MCFG 0x000000007CF48B20 00003C (v01 CORE COREBOOT 00000000 CORE 00000000) ACPI: SSDT 0x000000007CF49BC0 000FF8 (v02 CORE COREBOOT 0000002A CORE 0000002A)
I get the same output, both before running qemu for the first time, after a fresh reboot, and whilst running qemu - on the off chance, if VT-x is enabled whilst running qemu, then maybe the DMAR tables for VT-d might be available at the same time, but alas, no, it wasn't to be.
For VT-d to work, we would need a DMAR table in the BIOS.
Is this at all possible?
Edward.