Hi Gloup_Gloup,
I do not understand your first point, what job are you referring to? The paychecks of GA engineers? Of course VT-d needs additional initialization, just adding the option it is not enough. If you mean "VMM" by software, that is my last worry. If the hardware supports VT-d, then eventually the software can support it as well. I do not mind a bit of hacking.
I just disassembled the U1h UEFI BIOS module 2B341C7B-0B32-4A65-9D46-E1B3ABD4C25C (Smbios131) and found out that VTd should exist in the Setup menu (this can be configured at compile time). VT-d is a feature provided by the north bridge which was previously a separate feature of the chipset, but since Sandy Bridge it got integrated on the CPU itself.
Looking further in the
source code of AMI BIOS, it looks like VTd support is more a policy configuration rather than hardware availability (other than CPU/SB support). Presumably not to hurt sales of server boards.
Since the BIOS policy is configured to allow VT-d, there is one remaining barrier, the hardware (DRAM controller) must support it. (VT-d = Directed I/O, duh.) Support for VT-d is checked by looking at bit 7 on offset 0xe6 of the PCI device 00:00.0 (DRAM controller).
On Linux, one could run the following command:
dd if=/tmp/pcicfg-ext.bin bs=1 skip=$((0xe6)) count=1 2>/dev/null | xxd -ps
If you see "80" or something else with bit 0x80 enabled, then VT-d support is not available. Otherwise, initialization of VTd continues (init from DMAR ACPI tables). On my current SB CPU that does not support VT-d, bit 0x80 is indeed set. See page 81 of
http://www.intel.com/content/www/us/en/processors/core/2nd-gen-core-desktop-vol-2-datasheet.htmlNow, I will have to wait for my VT-d-capable CPU to arrive before I can test anything.
PS. this is an account I found via bugmenot, disregard all "personal details" of this profile.
