[SeaBIOS] VT-d not enabled on Chromebook Pixel 2013 Link & Chromebook Pixel 2015 Samus

[edward wandasiewicz]

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.