|| ||Linus Torvalds <torvalds-AT-linux-foundation.org>|
|| ||Ingo Molnar <mingo-AT-elte.hu>|
|| ||Re: ABI coupling to hypervisors via CONFIG_PARAVIRT|
|| ||Fri, 9 Mar 2007 11:51:09 -0800 (PST)|
|| ||Jeremy Fitzhardinge <jeremy-AT-goop.org>,
Zachary Amsden <zach-AT-vmware.com>,
Thomas Gleixner <tglx-AT-linutronix.de>,
john stultz <johnstul-AT-us.ibm.com>, akpm-AT-linux-foundation.org,
Rusty Russell <rusty-AT-rustcorp.com.au>, Andi Kleen <ak-AT-suse.de>,
Chris Wright <chrisw-AT-sous-sol.org>,
Alan Cox <alan-AT-lxorguk.ukuu.org.uk>|
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
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
- 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
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.
- 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
- 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 ;)
to post comments)