Windows 7/8 don't support xHCI USB controllers that are present in Kaby Lake. http://www.theregister.co.uk/2016/09/02/windows_intel_kaby_l...

I suspect this is mostly artificial and the EHCI emulation is still there but just fused off to encourage people to upgrade.

It's the "chipset" drivers, yes; but in the modern world all that hardware is on-chip and not meaningfully separable from the SoC. So sure, x86 code will run fine on the chip in any OS (e.g. Linux in virtualization under Windows 10). But you still can't boot Linux on it without drivers for the hardware.

In this case it's the SATA storage controller, which is configured by the BIOS in a mode that isn't compliant with the AHCI spec.

> In this case it's the SATA storage controller, which is configured by the BIOS in a mode that isn't compliant with the AHCI spec.

Not quite. It's the PCIe bridge, configured in a thoroughly nonsensical way that makes it pretend that an NVMe device (which is a PCIe device in its own right) is hidden behind a SATA controller.

That's what I gathered. It just means older operating systems won't be able to take advantage of new instruction sets, or as other commenters have pointed out, we won't see USB3/Bluetooth drivers that are guaranteed to work on the older chips.

Is that it, or is there more to this I'm missing?

Most ordinary Intel Core CPU's incorporate a graphics engine with multiple cores. So under Linux, they can use proprietary graphics drivers. With a discreet GPU, the story becomes even muddier, because Intel's Optimus (a technology that switches between discreet and on CPU graphics for power savings) is not fully implemented by Nvidia's Linux drivers. So there's no dynamic switching like there is in Windows.

>Intel's Optimus

Wait, wasn't Optimus Nvidia's baby?

Yes. The confusion is understandable though because Optimus allows you to switch between integrated GPU (Intel) and graphics card GPU (Nvidia).