Posted by: Ed Tittel
SLAT requirement ensures acceptable performance for Windows 8 Hyper-V, why SlAT matters for Windows 8 Hyper-V
So now that I’ve been introduced to Second Level Address Translation (SLAT) as a requirement for Hyper-V on the upcoming release of Windows 8 (see my recent blog on this discovery at edtittel.com: “Be Prepared for Windows 8 Hyper-V Gotcha“) I’ve been wondering about why it has to be this way. So I dived into the newly-created Windows 8 Developer Preview MSDN forums to see what I could learn there, and in the context of a discussion entitled “Hyper-V cannot be installed on Lenovo Thinkpad W500” I found a lovely source of enlightenment on this topic. While it is technical enough to make some eyes bleed, it does provide a key insight into the SLAT requirement.
Microsoft\’s Virtualization Guy Explains Hyper-V and SLAT
This source is Ben Armstrong’s blog from waaaaaaaaaaaay back in November 2009 entitled “Understanding High-End Video Performance Issues with Hyper-V.” In a very tight nutshell, the upshot of this posting may be summarized as follows:
1. High end graphics cards require frequent and resource-intensive/expensive memory allocations that come from using a PAGE_WRITECOMBINEprotection operation in the hypervisor.
2. This requires the kernel memory manager to flush the translation lookaside buffer and the page cache, which in turn sends an intercept into the hypervisor.
3. Lots of resource intensive hypervisor operations like this turn a (normally) infrequent operation into something frequent enough to hamper or cripple performance. There’s a great diagram in the blog post that shows why a hypervisor falls prey to this limitation, while a virtual machine manager (VMM) like that found in Virtual PC or Virtual Server remains immune to the problem. And interestingly, the faster and more capable the video card in a PC the more likely it is to fall prey to this problem.
One fix mentioned in Armstrong’s blog reads as follows “Get a system with Second Level Address Translation (SLAT).” This lets the hardware handle multiple translation lookaside buffers, on a one-per-VM basis (which is just what’s needed to sidestep the potential performance bottleneck that could otherwise occur). It looks like Microsoft simply opted to avoid potential performance problems from older hardware that might otherwise experience significant delays on the desktop to bypass potential customer complaints. In light of Armstrong’s admonitions to use the SVGA driver, choose a low-end graphics card, or turn off advanced graphics features, I find this decision “interesting” (in the sense of the Chinese curse) but also eminently understandable and defensible. But I still sigh to think of my otherwise very capable quad core Yorkfield processors (QX9650s, in fact) being consigned to the scrap heap of history (or turned into hand-me-downs) because they can’t run Windows 8 Hyper-V.