linux-kernel - Re: Xen & VMI?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 06 Mar 2007 19:06:02 -0800
From:	Zachary Amsden <zach@...are.com>
To:	Rusty Russell <rusty@...tcorp.com.au>, Ingo Molnar <mingo@...e.hu>
CC:	"Nakajima, Jun" <jun.nakajima@...el.com>,
	virtualization <virtualization@...ts.osdl.org>,
	Roland McGrath <roland@...hat.com>,
	Anthony Liguori <anthony@...emonkey.ws>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Jan Beulich <jbeulich@...ell.com>
Subject: Re: Xen & VMI?

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/