As I don't know how mailing list works (First time in one. Seriously, after one decade using Forums I see them much more convenient and a mailing list quite hard to use and archaic), I hope that when I replied you, it will look nested in the tree of this Thread's tree.
> Strictly speaking there are two types of VT-d - VT-d, and VT-d2. VT-d
> is the initial virtualisation for directed I/O introduced in the
> Conroe era of Intel processors, whilst VT-d2 arrived with the Nehalem
> architecture.
>
> VT-d is mostly a chipset technology in particular a memory controller
> feature not a processor feature. Additionally this varies on an
> individual motherboard basis - the X38/X48 chipsets have the potential
> to support VT-d for instance, but it must be supported in the BIOS (it
> needs various tables, it's not just an on/off switch).
I did some more research and you're right. VT-d Hardware support was actually introduced with the Wolfdale platform, specifically Chipsets Q35, Q45, X38, and X48. I just never paid attention to it before Nehalem:
http://en.wikipedia.org/wiki/List_of_intel_chipsets#Core_2_chipsetsThe Motherboard that the guy from the videos I linked before was using is a Intel DQ45CB, so he should have VT-d support (It actually mentions it on the description of some of his other videos). This pretty much solves my original question, as in order to do the passthrough, you need to have it virtualized. So IOMMU virtualization is a must.
Just for the record, according to another Wikipedia list, on the old Wolfdale platform, VT-d support ALSO requiered some degree of Processor support besides Chipset:
http://en.wikipedia.org/wiki/List_of_Intel_Core_2_microprocessors#.22Wolfdale.22_.2845_nm.29It says that Core 2 Duo E8200 (Wolfdale) didn't had VT-d support. A check on Intel Ark shows that difference, if you compare a C2D E8200 to a E8300:
http://ark.intel.com/products/33909 C2D E8200
http://ark.intel.com/products/35070 C2D E8300
However, the C2D E6300 (Conroe) of the guy that did the videos doesn't show VT-d support as feature, neither:
http://ark.intel.com/products/27248/To be honest, considering that the Memory Controller responsible of VT-d support was at the Chipset, I suppose that Processor support was pretty much a cosmetic thing simply to enforce you to have to spend on a more expensive Processor to have that feature, a common Intel practice. But as in the C2D E6300 it isn't, it leaves me thinking if you really needed Processor support or they simply forgot to add it as feature on the earlier Conroe models. Not that it matters at this point, as I don't think that anyone right now would get a 6 years old system for GPU virtualization purposes.
> With the introduction of Nehalem, the Memory Controller Hub was of
> course moved into the processor and for some reason certain processors
> (usually the K models) are not enabled for VT-d.
I always took notice that the K models doesn't got VT-d support. The exception is the Core i7 3930K (Sandy Bridge-E), that is more that twice as expensive as the Core i5 2500K or the newer Ivy Bridge equivalent. For some reason, Intel doesn't want that people that wants to have overclocking freedom uses IOMMU virtualization. A pretty nasty market segmentation tactic, if you ask me, as a K model is more expensive due to the Unlocked Multiplier and usually slighty better Integrated GPU, yet you lose VT-d, vPro and TXT.
Besides, I don't have entirely clear if after Nehalem you still need Chipset support for VT-d, or now that it is a Processor feature, its support is Chipset independent. Considering that in order to make use of the Unlocked Multiplier of a K series Intel Processor you need to have some specific Chipsets (Usually the Z series and some P), and that also for vPro you need another different specific Chipsets series (The Q series inteded for business), I wouldn't be surprised if VT-d would need a specific Chipset too besides Processor support, but I couldn't find any sort of artificially imposed Hardware limitation.
At least, I find weird what happens on the AMD side: If the Memory Controller was integrated to the Processor during the K8 era, I don't get why AMD-Vi is a Chipset feature. Yet there is no mention that you need a specific Processor to use it (Or some are artificially limited like Intel does), if all them includes support for it, or if support isn't actually related to the Processor itself and only Chipset and BIOS.
> Nehalem and the
> equivalent AMD chips also support Second Level Address Translation
> (EPT on Intel, RVI on AMD) which offers a substantial speedup for
> various operations, and in particular virtualised graphics cards in
> some instances. The latter is supposedly the reason why Windows Phone
> 8 development (which needs Hyper-V) also requires a SLAT capable CPU.
At least from AMD side, RVI seems to be supported from pretty much everything after K10 Barcelona, so it doesn't seem to be any type of show stopper:
http://support.amd.com/us/kbarticles/Pages/GPU120AMDRVICPUsHyperVWin8.aspxIt is still good to know that.
> As above, you need a processor that
> supports VT-d, a chipset that supports it and a BIOS that is enabled
> for it and actually works. For instance, I have passthrough working on
> my pre nehalem system with a basic Matrox card, but not yet an AMD
> configuration. The BIOS did not support VT-d initially until an update
> was applied.
One of the things that I mentioned in the Thread that I linked in my original Post here, is that is pretty much unknow if you have proper, working BIOS support until you actually give the Motherboard a try, and nothing guarantees you that the Motherboard manufacturer will provide you later with a BIOS upgrade. At least on AMD Motherboards, this seems to be a huge issue, no idea on current Intel platforms.
I was thinking about going to Coreboot (An open source BIOS replacement) mailing list precisely to ask about this matter, so in case that an AMD Motherboard got a supporting Chipset but the BIOS doesn't works properly (If I recall correctly, a common issue on AMD Motherboards was that the ACPI IVRS tables were missing), I could at least have a backup alternative.
