AMD announces Pacifica specifica

AMD ANOUNCED PACIFICA yesterday, and while the full spec is not going to be released for another few weeks, there is enough there to get an idea of what it is looking at doing. Pacifica is basically hardware assist for virtualisation, a topic I covered on the Intel side a few weeks ago (parts 1, 2, 3, and 4). AMD's release, while not the full spec, shows some distinct differences.

From a 1000 foot overview, both technologies do about the same thing. Virtualisation in software is a drag on performance, 10-40%, but that is highly dependent on workload. Both Pacifica and Vanderpool aim to get this as close to zero as possible, and do it in roughly the same way. They each have a privilege state higher than Ring 0, and they each give you enough ways to trap a VMExit to drive an assembly programmer mad.

Pacifica goes for the same type of transparent extensions as the AMD philosophy on 64 bit, basically that it is there, use it if you want. If you don't want to use it, it will not compromise the non-virtualised apps. When Pacifica is rolled out across all AMD product lines in 2006, you can use it when you want, how you want, if you want.

The burning question on everyone's mind is, is it Vanderpool compatible? The short answer is no, and while I don't have the full spec yet, I don't think it even uses the same mnemonics. While this may seem like a down side, Pacifica adds some tricks, and brings enough additional feature into the mix that direct compatibility is probably a lost cause.

The biggest addition to Pacifica is the memory controller. On the K8 based chips, the memory controller is on board where as on Intel platforms, it is on the north bridge. This allows AMD to add virtualisation features to the memory controller in a way that would be hard for Intel to duplicate. While the details are not out, it would really surprise me if AMD did not add a much stronger level of memory protection to each VM, and lessen the memory related overhead on a VM entry or exit. Latency reduction has benefits in a lot of ways.

The double edged sword of the memory controller is probably not as bad as it seems. The added features mean you are not compatible, and that means each ISV will have to write two sets of VMs, one for AMD, one for Intel. This adds time and expense to any VM development effort, which is never a good thing. On the up side, you potentially gain speed and efficiency.

In the case of Pacifica, I don't think it will be all that bad though, mostly because there are not many companies writing VMs, a dozen or so at most. They are names like VMWare and Microsoft, but also include a smattering of open source projects, and AMD has been actively working with them all. Since Pacifica is a year away from buyable silicon, there is more than enough time to get the virtual ducks in a row. Add in that anything this low level, lower level than even OS optimizations, will pretty much need to be hand tuned for each platform, and the differences in specs become mostly academic.

The one worry I have is whether AMD will put out the tools needed for VM writers. With flat out different instruction sets, you can't use the same tools you would for Intel chips, so you have to start from zero. AMD's plan here appears to be the same as it did with AMD64, work with the open source community, put out emulators and tools, and start a grassroots community. This time, it is going to put out an open hypervisor, and when silicon emerges, you can add a plug in that takes advantage of the new shiny bits. Not a bad strategy.

So, Pacifica basically does what Vanderpool does, lowers the cost of virtualisation by taking things that need thousands of cycles to do in software, and runs them in far fewer cycles in hardware. It is not Vanderpool compatible, but then again they are promising that it does more better by leveraging the unique aspects of the K8 architecture. ISVs are on board, and all are beavering away so that when silicon hits the street, all will be happy and is should just work. When the tech specs come out in the near future, we will know for sure. µ