[wtallis]

It's a shame that Intel only advertises VT-d as an enterprise-oriented virtualization feature and only offers it on a few models of consumer CPUs. They should have treated it like the NX bit and made it universal so that operating systems could rely on it.

It's frankly disgusting that they are withholding an efficient hardware solution to an entire class of security problems, when they could make it available to almost everyone with a microcode update.

[mmastrac]

Isn't it on all the i5/i7 CPUs? I might be mistaken, but I can't recall a time in recent history I had a CPU without it.

[wtallis]

Only the two most recent overclockable models (Devils Canyon variant of Haswell) have VT-d, and artificially excluding all the budget product lines is not a responsible way to handle what should be seen as a security feature first and foremost.

[rwh86]

That's not what I see from searching Intel's ARK:

http://ark.intel.com/search/advanced

Here's a list of Intel's latest CPU series, and how many have VT-d support:

* 5th gen i7: 5/5

* 5th gen i5: 6/6

* 5th gen i3: 5/5

* 4th gen i7 extreme: 2/2

* 4th gen i7: 42/49

* 4th gen i5: 46/55

* 4th gen i3: 5/37

So the summary: all but the slowest gen 4 i5 and i7 chips have it, and all gen 5 chips currently released have it.

edit: formatting

[wtallis]

For the purposes of this discussion, you really should be looking at more than just the current generation of chips, because the installed base that OS vendors have to worry about includes a lot of processors that are more than 18 months old, and a lot of processors from the budget product lines. The 5th generation parts so far are just ultra-low power tablet and ultrabook CPU, so almost all of the 4th-gen Haswell parts are still current.

Intel's been a lot better about including VT-d on laptop chips, especially recently, and haven't disabled it on the consumer rebrands of their server chips (the "i7 Extreme" parts) in the past few generations, but did on earlier generations. Among the desktop parts, they've been all over the place, and most notably all but two of their flagship overclockable desktop processors (-K models) have had it disabled. Those models have most likely outsold their i5 and i7 counterparts that do have VT-d, and probably themselves been cumulatively outsold by the i3, Pentium, and Celeron processors that also lack VT-d. A raw count of the model numbers shows that in the time since VT-d has been released, the desktop processor models have been split 134 to 63 in favor of not supporting it.

The overall picture is that VT-d support is at least as hit-or-miss as HyperThreading support, which the Steam Hardware Survey finds to be present on about two thirds of Intel machines. Motherboard firmware support for VT-d is even worse, and of those that do support it, it's usually off by default.

[nitrogen]

Only the two most recent overclockable models (Devils Canyon variant of Haswell) have VT-d...

This means that previous *-K (multiplier-unlocked) models have VT-d disabled, right? So you have to choose between overclocking and VT-d.

[wtallis]

Yes, although prior to Haswell it was still possible to do a moderate amount of overclocking on the non-K models that do have VT-d; the multiplier could be increased by about the same margin as the Turbo Boost feature uses, and you still got Turbo on top of that. Haswell marked a shift from a limited-unlocked multiplier to a fully-locked multiplier for the non-K parts.

[garrettr_]

I'm not familiar with the security benefits of VT-d; might you have a link to a whitepaper or another resource?

[wtallis]

VT-d is an I/O MMU: it does address space translation for DMA. In a virtualization scenario it enables DMA between real peripherals and virtual machines. In a security context it means you can control which parts of memory a malicious peripheral can DMA to, instead of granting it access to the full physical address space. In a more general OS driver context, it means that you don't have to worry about reserving low memory addresses for doing DMA with devices that only support 32-bit addressing.

[wyldfire]

Well, I doubt Intel sees it as a security feature first and foremost. But even if they did, they don't have an obligation to be "responsible" in how they market their features. Many of their pricing choices ultimately end up being related to yield. If they need to devote more transistors in order to enable an IOMMU, seems like it makes sense to charge more for it.

[wtallis]

Core count, clock speed, and cache quantity are related to yield. HyperThreading, VT-d, AVX, Turbo Boost, AES-NI, TSX, and ECC are all too integral to the core design; they're physically present on all chips and it is extremely unlikely for a manufacturing defect to affect one of those features without otherwise crippling the chip. Those features are used for product segmentation that is not driven by any real marginal cost.

[wtbob]

> But even if they did, they don't have an obligation to be "responsible" in how they market their features.

Intel is a corporation; its shareholders are shielded from personal financial liability for its errors; thus is seems appropriate that it be required to be responsible in exchange for the privileges it has been granted.

[pcunite]

You're thinking of VT-x.