Since publishing my rant a few days ago, I’ve discovered a few more motherboards which CLAIM to support VT-d (Intel Virtualization Technology for Directed-IO). Of course you need a non-K flavour of Sandy Bridge CPU as well (ie i5-2400, i5-2500, i7-2600).
So here’s the list so far, which I’ll update as I find more:
- Intel DP67BG (Confirmed, see comment by Michael)
- ASRock P67 (All of them, last time I checked – i.e. Pro, Fatal1ty) (Seems to be bogus according to Brian)
- ASRock H67M (And all variants)
- Foxconn H67S and variants
- Foxconn P67A
- ASUS P8H67-V and P8P67? (See below)
- BIOSTAR TP67XE and variants
- BIOSTAR TH67XE and variants
There’s a good chance that if one of the H67/P67 boards from the same manufacturer (i.e. ASRock and Foxconn) have VT-d, all variants have it too. You can check by searching VT-d in the product manual.
Update 6/02/2011 – Latest Asus P8P67 manual (E6307) shows the VT-d option under “System Agent Configuration”. Is this a new addition or something I missed before I’m not sure. Quick check of other Asus boards ie P8P67 EVO or P8H67-M indicates they don’t have it. Exception is P8H67-V which seemed to have it from the beginning. It seems there’s hope for those with Asus boards.
Update 24/03/2011 – None of the boards except for the Intel one seems to support VT-d even if they claim to. There are continuing claims that P67/H67 doesn’t support VT-d.
Hello again,
I just wanted to update you on my efforts. I’ve not been able to get VT-d working on the Asus P8Q67-M. However, tonight I purchased an ASRock Z68M/USB3. After swapping the boards, I’m getting dmesg output that leads me to believe that indicates it does work. I’ll post back when I can pass something through.
Anyway, here is from my dmesg log:
dmesg | egrep -e DMAR -e IOMMU
[ 0.000000] ACPI: DMAR 00000000bcdcccf8 000E8 (v01 ALASKA A M I 00000001 INTL 00000001)
[ 0.000000] Intel-IOMMU: enabled
[ 0.016479] DMAR: Host address width 36
[ 0.016482] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[ 0.016489] IOMMU 0: reg_base_addr fed90000 ver 1:0 cap c0000020e60262 ecap f0101a
[ 0.016492] DMAR: DRHD base: 0x000000fed91000 flags: 0x1
[ 0.016497] IOMMU 1: reg_base_addr fed91000 ver 1:0 cap c9008020660262 ecap f0105a
[ 0.016500] DMAR: RMRR base: 0x000000bcde1000 end: 0x000000bcdf3fff
[ 0.016502] DMAR: RMRR base: 0x000000bd800000 end: 0x000000bf9fffff
[ 0.016504] DMAR: No ATSR found
[ 0.016576] IOAPIC id 0 under DRHD base 0xfed91000 IOMMU 1
[ 1.104618] IOMMU 0 0xfed90000: using Queued invalidation
[ 1.104622] IOMMU 1 0xfed91000: using Queued invalidation
[ 1.104625] IOMMU: Setting RMRR:
[ 1.104634] IOMMU: Setting identity map for device 0000:00:02.0 [0xbd800000 – 0xbfa00000]
[ 1.104795] IOMMU: Setting identity map for device 0000:00:1d.0 [0xbcde1000 – 0xbcdf4000]
[ 1.104814] IOMMU: Setting identity map for device 0000:00:1a.0 [0xbcde1000 – 0xbcdf4000]
[ 1.104825] IOMMU: Prepare 0-16MiB unity mapping for LPC
[ 1.104832] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 – 0x1000000]
I can also verify that the intel DQ67SW supports IOMMU. There is however a caveat. The only PCI slot on the board shares intA with the network card, the video adapter, the serial port and the SATA ports. Virtualbox, at least, does not work with shared interrupts (yet). Oddly, there is nothing on intD! How lame is that? Put the only PCI card on a shared line and don’t use intD at all? In all fairness, it may be used by something that I have disabled in the BIOS. Intel does not give out the interrupt assignments (they claim I have to sign an NDA to get them???). In any case, simply using “lspci -vv” will list them all anyway.
I have found an ASUS board for the AMD3+ socket which supports IOMMU and has an unshared interrupt on the (only) PCI slot (The asus MSA99X EVO, see page 32 of the manual). I have not yet tested this MoBo however.
We bought ASRock H67M but failed to make it work. The BIOS is updated with VT-d and local X2APIC enabled, but we kept having “No IOMMU found.” in KVM. The dmesg log shows “Intel IOMMU: enabled” but I see no follow-up IOMMU message. I will try to get ASRock Z68M tomorrow and see if that works.
By the way, which kernel version are you guys using? We are using Cent 6.0 with 2.6.32-71.el6 kernel.
Enabling SR-IOV/VT-d is pretty frustrated but this post sheds some light here…Thanks!!!!
@Mark Sung:
“By the way, which kernel version are you guys using? We are using Cent 6.0 with 2.6.32-71.el6 kernel.”
That kernel version is too old. I had a look at the VBOX driver source, and there is a conditional preventing compilation of the IOMMU code if the kernel version too old (IIRC, it must be at least 2.6.35). You can’t just override the conditional either, since the names of some of the symbols were changed in the kernel sources. When I updated the Kernel to a newer version, the IOMMU was then found and I could assign the PCI card to a virtual machine. However, in my case (with the Intel DQ67SW) the virtual machine wont start because the PCI slot shares an interrupt line (see my last comment).
Did anyone get it working or can confirm working on Asrock Z68M/USB3? About to buy a mATX board and would be nice to have a working one for VT-d
ASUS P8H67 supports VT-d with for sure. UEFI bios 3603 on board and citrix xenserver installed. winXP and win 7 see my nvidia gtx560 vga, but i had problems to start it. new drivers installed but still kod 43 error
“ASUS P8H67 supports VT-d with for sure.”
You mean it have DMAR table but no vt-d switch in the BIOS and nobody have been abble to make it works ? I mean do you have a concrete proof that it works when Asus tells last year that it will never work for H67 because they stopped their effort (too many tests didn’t pass and they concluded it didn’t worth it).
Pingback: Mini ESXi Lab Hosts - VirtuallyHyper
do you provide list of z87 motherboard?