Message-ID: <20070309192420.GA27747@elte.hu>
Date:	Fri, 9 Mar 2007 20:24:20 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Zachary Amsden <zach@...are.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	john stultz <johnstul@...ibm.com>, akpm@...ux-foundation.org,
	LKML <linux-kernel@...r.kernel.org>,
	Rusty Russell <rusty@...tcorp.com.au>, Andi Kleen <ak@...e.de>,
	Chris Wright <chrisw@...s-sol.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: ABI coupling to hypervisors via CONFIG_PARAVIRT


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Fri, 9 Mar 2007, Ingo Molnar wrote:
> > 
> > yes - but we already support the raw hardware ABI, in the native 
> > kernel.
> 
> Why do you continue to call paravirt an ABI?
> 
> We got over that. It's not. It's an API.
> 
> VMI is an ABI.

Unfortunately i still dont see where i'm wrong, and i'm really trying to 
understand your argument. Is your argument that as long as an ABI (VMI) 
is never directly used but only used via wrapper functions 
(paravirt_ops), it has no effects whatsoever on the flexibility of the 
rest of the software and ceases to have any negative ABI effects? In my 
opinion that is an absurd (and incorrect) point so i guess you must mean 
something else, but i really cannot think what that is.

I never said paravirt_ops is an ABI. I say that the ABI(s) _behind_ 
paravirt_ops [in the backend] /does/ limit Linux, even if wrapped, 
inevitably, and that i'm simply worried about having 4-5 independent 
ABIs behind each paravirt_ops variant each creating a web of design 
constraints on the rest of the kernel. To quote a past email of mine:

|| 'paravirt ops can take care of it' - but that is just blatantly 
|| _FALSE_: the ABI 'behind' the paravirt_ops 'shines through' via 
|| functional coupling

it doesnt matter in how big letters the wrapper functions have 'freedom' 
written on them, the _real_ constraint is the user's expectation to have 
the hypervisor work with Linux that worked with that particular VMI ABI 
in v2.6.21. So the user wants to have its hypervisor 1.12 work with 
Linux v2.6.22 - without having to update the hypervisor. And Linux 
v2.6.23. Etc. /That/ is the 'ABI effect' i'm worried about. It is a 
"compatibility web" that gets more and more entangled with every new 
paravirt_ops implementation added.
 
In practice, when a problem comes up during code rewrite, 90% of the 
time we can probably find a way around it via paravirt_ops and the 
backend, but i'm simply worried about the remaining 10%. And that 10% is 
not hypothetical at all, should i cite specific examples of problems 
that i think cannot be solved via Linux-only modifications?

I'm also worried about the sheer QA inertia of having an additional 4-5 
hypervisor-ABI constraints on the correctness of the kernel, in addition 
to the 2 main CPU variants we have at the moment.

If we said "paravirt_ops must behave like real hardware" then we'd 
probably remove some of that risk (although enforcement is still an 
issue). But we _specifically_ say that no, it doesnt have to behave like 
real hardware. We allow shortcuts, we allow modifications of behavior - 
and that's good in quite many cases. But we allow really weird hacks 
like the .safe_halt() thing. Our only present requirement it appears is 
that "it works with today's hypervisor" - and that requirement 
automatically transforms itself into: "all future kernels will work with 
all past versions of the hypervisor".

	Ingo
-
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/

Powered by blists - more mailing lists