Re: Xen & VMI?

Zachary Amsden
2007-03-07T03:06:06Z

Rusty Russell wrote:
> On Tue, 2007-03-06 at 21:37 +0100, Ingo Molnar wrote:
>
>> maybe i shouldnt call it 'VMI' but 'the paravirt ABI'. I dont mind if
>> it's the Xen ABI or the VMWare ABI or a mesh of the two - everyone can
>> map their own internals to that /one/ ABI.
>>
>
> I think it's an excellent aim, but it's *HARD*. I rejected this
> approach earlier because I'm just not smart enough. (Yet?)
>

With VMI, I think we came within 90% of getting a cross vendor
paravirt-ABI that satisfied everyone's needs. Nobody is smart enough to
figure out the last 10% - it needs cooperation, trial, error, and
experience dealing with each other's hypervisors.

> The Linux side is fairly stable. The hardware side is changing, and the
> hypervisor side is changing. This means the ABI will churn fairly fast.
> The hypervisors are very different, which means the ABI will be very
> wide.
>
> We could start with VMI and try to support Xen, KVM and lguest. It
> would at least give us a better idea of the scope of the problem. But
> IMHO it's a *huge* job.
>

Surely, given time, the technical issues can be worked out. In the
meantime, the hardware has evolved, and many of the points that are now
important have changed - and new issues have come into play that we
can't anticipate yet. At some point, we will hopefully converge, but we
might not, and it is a huge job. UDI had similarly lofty goals. It was
started in 1998. Where is it today?

But this isn't the problem. The problem is that nobody wants a single
ABI. Just like no hardware vendors want a fixed ABI for their
hardware. They need to innovate independently, and time to market and
features are more important than being binary compatible with a bunch of
competing vendors. They want to differentiate, and break away from an
ABI, and as history repeats, again and again, this happens eventually
with every ABI.

So once the ivory tower is built, and you let all the kids in to play,
they are going to have a party and you are going to start noticing chips
and eventually cracks, and eventually the tower will go into disrepair
and fall because somebody else has built a new and better one further
down the road. Why go through that exercise if nobody sees any tangible
benefit from it today?

Paravirt-ops avoids this because it is an API, and because it is
flexible, and because it can change with the kernel, and because it
doesn't lock you into a legacy way of doing things, it allows you to
fork and adapt and push legacy and future compatibility issues into the
vendor backend modules, like VMI, where they should belong.

Zach