Date:	Fri, 9 Mar 2007 11:51:09 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
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



On Fri, 9 Mar 2007, Ingo Molnar wrote:
> 
> 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)

No.

My argument is utternly and *purely* that you've been confusing the 
discussion by using the wrong terms, and as a result, you've been 
discussing things that aren't *relevant*.

You haven't been saying anything constructive.

For example, here's a *constructive* thing you could have said, and never 
actually did:

 - paravirt_op->write_apic should not exist

   anything that needs to write to the apic should ether

    (a) have been caught much earlier in the paravirt stack, ie it's a 
	"disable interrupt" kind of operation, and should never even have 
	gotten to the APIC write in the first place, but been handled by 
	the paravirtualized handler.
    (b) just be emulated as an APIC write (and if the emulation isn't good 
	enough, screw it)

In other words, to be *constructive*, you need to point out particular 
and practical problem spots, instead of just ranting about any 
"paravirtualized ABI".

Of *course* there is an ABI at some point behind any API. Why do you harp 
on that? It's irrelevant. Any API will always end up being instantiated 
into a binary thing at some point, and that binary thing will have to work 
with some particular version of a hardware/infrastructure combination, but 
that has *nothing* to do with anything.

The x86 instruction set is an ABI. Our API's eventually tend to be 
compiled to something like that ABI, and yes, some ABI's may not be able 
to do certain things. For example, on the 32-bit x86 ABI, there are no 
interfaces for address space identifiers, and the wrappers become a no-op 
that just don't do anything, and if you want fast context switches between 
two contexts, you're screwed.

Similarly, maybe the VMI ABI doesn't allow for something that the kernel 
wants to do efficiently. Big deal. What relevance does that have to do 
with anything, except the fact that if true, the VMWare people are 
screwed? It's *their* problem.

So please

 - point out things that are badly done. I agree that apic_write() simply 
   shouldn't be an ABI point at all. But do so *directly* without some 
   ranting about other things that aren't relevant. Your "1400 hooks" rant 
   was pointless - there aren't 1400 hooks at all. There are 1400 
   call-sites, but that's like saying that the "mov" operation is a bad 
   instruction, because there are 5 million mov instructions in the 
   kernel.

 - Realize that if VMI has problems, it's not *your* problem, or even the
   kernels problem. It's purely a VMI problem. I don't understand why you 
   care, or why you think we should care.

 - and I guess we can also stop cc'ing me in the first place. I don't even 
   think virtualization is very interesting. I'd much rather flame people 
   about bad taste in more important areas ;)

Thanks,

				Linus
-
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