OpenSparc Hypervisor Specification

As I mentioned here below, Sun is adding hardware virtualization assistance to future Sparc processors. This is deeply weird, because the only two sparc operating systems anybody cares about (Solaris and Linux) are already open source, and hence amenable to paravirt techniques. Given Sun's apparent commitment to Xen, I continue to regard the use of hardware virtualization assistance as a head-scratcher.

Well, now Sun has their own hypervisor API spec, not obviously related to the Xen API. Does this make for yet another competing hypervisor API in the just-getting-started Xen vs. VMware's VMIM fracas? Some sort of hedge on the part of Sun, just in case the Xen romance doesn't pan out? I wonder.

Edit: John Johnson very nicely points out that I'm being an idiot in the comments. Thanks!

Hola amigos!

I know it's been a long time since I rapped at ya'. Here we are, in '06, more than half-way through the "oughts." How will our decade be remembered? I shudder to think.

It looks like Sun is going to build hardware virtualization support into the newer niagara parts. I must confess that this one is a bit of a head-scratcher for yours truly. The only OS'es of significance that run on sparc are Solaris and Linux. Persons running Linux on sparc hardware for anything other than software development or entertainment purposes are, not to put too fine a point on it, probably out of their cotton-picking minds. So, why does Sun think this will enable them to sell more servers, especially given that their (oh, so horrendously named) BrandZ magic sauce lets most Linux applications run on top of Solaris? Beats me. Perhaps they felt they had to be able to counter Intel's substantial VT hype?

Speaking of which ... Simon Crosby was at Stanford flogging Xen yesterday. While I was unfortunately not able to make it, I perused the slides a tad. With foil titles like "XenSource Delivers Virtualization Value", there isn't much academic veneer on this very business-oriented talk, so, as a non-expert, I can do little to address the projections, pie charts, etc. However, I notice from slide 27 that they're relying on page-table switching to protect virtual kernels from virtual applications on 64-bit architectures. The slide is oddly silent on what a flaming performance disaster this approach constitutes. As if turning every virtual system call into two hardware system calls weren't enough, we're now piling a TLB flush on top of that cost, too. I'll be interested to see how their 64-bit performance fares compared to our offerings. But hey! Who cares about performance when you're "the Open Industry Standard," "Unlocking Platform Innovation"! I'm also tickled at the extended treatment of Xen's newfound live migration capabilities, as if we hadn't shipped the very feature they're aping in 2002.

I know, I know, it's a low blow. VMware has some pretty goofy marketing material out there, too. We're not presenting it in front of the Stanford CS department, though. For the most part. I think.