Share via

Everything you wanted to know about SR-IOV in Hyper-V Part 4

  • Article

So far in this series, we have discussed the “why” question, and identified three dependencies for SR-IOV in Hyper-V in Windows Server “8” beta:

  • System hardware support in the form of an IOMMU device
  • A PCI Express networking device which has SR-IOV capabilities
  • A driver model to support both PF and VFs.

This part of the series adds one more major component to that list, and one minor one. The minor one is that the system must support SLAT (Second Level Address Translation). In the server ecosystem, you would be hard pushed to find a system which has an IOMMU chipset which didn’t have a SLAT capable processor, so to almost all intents and purposes this is a non-issue.

The major component missing so far is system firmware, or BIOS. While we have a multi-page document shared with the hardware ecosystem firmware developers describing the necessary changes (and other minor dependencies), the details of that document are beyond what is necessary to understand SR-IOV from an end-user perspective. What you do need to understand though is that without those changes, Hyper-V cannot enable SR-IOV, even if we have chipset support in the form of an IOMMU device actually present.

There are a couple of things from the necessary firmware changes which permeate into the end user usage of Hyper-V which I will cover in more depth in a “debugging why SR-IOV isn’t working” part of this series. For now I’ll just say that one is PCI Express Native Control being transferred to the operating system, and the other is support for a chipset issue workaround.

We have been working with system vendors for a long time to make sure that systems are available for you to try out SR-IOV on in Windows Server “8”. We are on the cusp of the next generation of release cycles from system vendors over coming months, and there will be much wider support in those latest generation platforms. However, for now, the numbers of systems which can be used are relatively limited. Certainly do not expect SR-IOV to work on desktop platforms (or laptops) due to the firmware requirements. This is very firmly (pun intended) a server based feature. For up to date details, you should contact your system manufacturer for information for BIOS versions and platform support on existing hardware. There are supported platforms available today from Dell, Fujitsu and HP, and other OEMs have systems in “best effort” support. Some of this information is listed in the release notes for Windows Server “8” beta.

One thing I would point out though is that some BIOSs we have seen have more than one place where SR-IOV must be enabled. So please do take the time to make sure you follow your system vendors instructions accurately.

An interesting presentation 4 years ago at WinHEC 2008 was made by my colleague, Jake Oshins. It has some further references if you are interested in further reading about some of what has been covered so far in this series of posts. Some information has changed, but most still applies.

So now that we have enumerated all the hardware and software components needed for SR-IOV support which are (largely) outside the control of Microsoft, the next part of this series is where we’ll start to see SR-IOV in action.

Cheers,
John.

Comments

  • Anonymous
    November 19, 2015
    With Windows Server 2016, we're introducing a new feature, called Discrete Device Assignment, in