Thread (31 messages) 31 messages, 7 authors, 2006-08-08

Re: [PATCH 3/4] x86 paravirt_ops: implementation of paravirt_ops

From: Rusty Russell <hidden>
Date: 2006-08-07 06:13:45
Also in: lkml

On Mon, 2006-08-07 at 07:39 +0200, Andi Kleen wrote:
On Monday 07 August 2006 06:47, Rusty Russell wrote:
quoted
This patch does the dumbest possible replacement of paravirtualized
instructions: calls through a "paravirt_ops" structure.  Currently
these are function implementations of native hardware: hypervisors
will override the ops structure with their own variants.
You should call it HAL - that would make it clearer what it is.
People get visions of grandeur when HAL is mentioned: they think it'll
abstract everything.  I really only want to do the minimum needed for
the hypervisors we have on the table today.

Maybe one day it will abstract everything, then we can call it a HAL.
But I won't be doing that work 8)
I think I would prefer to patch always. Is there a particular
reason you can't do that?
We could patch all the indirect calls into direct calls, but I don't
think it's worth bothering: most simply don't matter.

The implementation ensures that someone can get boot on a new hypervisor
by populating the ops struct.  Later they can go back and implement the
patching stuff.
It would be better to merge this with the existing LOCK prefix patching
or perhaps the normal alternative() patcher (is there any particular
reason you can't use it?)

Three alternative patching mechanisms just seems to be too many
Each backend wants a different patch, so alternative() doesn't cut it.
We could look at generalizing alternative() I guess, but it works fine
so I didn't want to touch it.

Rusty.
-- 
Help! Save Australia from the worst of the DMCA: http://linux.org.au/law
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help