On 8/4/06, Chris Wright <[email protected]> wrote:
* Andrew Morton ([email protected]) wrote:
> I must confess that I still don't "get" paravirtops. AFACIT the VMI
> proposal, if it works, will make that whole layer simply go away. Which
> is attractive. If it works.
Paravirtops is simply a table of function which are populated by the
hypervisor specific code at start-of-day. Some care is taken to patch
up callsites which are performance sensitive. The main difference is
the API vs. ABI distinction. In paravirt ops case, the ABI is defined at
compile time from source. The VMI takes it one step further and fixes
the ABI. That last step is a big one.
There are two basic issues. 1) what is the interface between the kernel
and the glue to a hypervisor. 2) how does one call from the kernel into
the glue layer.
Getting bogged down in #2, the details of the calling convention, is a
distraction from the real issue, #1. We are trying to actually find an
API that is useful for multiple projects. Paravirt_ops gives the
flexibility to evolve the interface.
One feature I found missing at the paravirt patches is to allow the
user to forbid the use of paravirtualization of certain features (via
a bitmask on the kernel commandline for example) so that the execution
drops into the native hardware virtualization system. Such a feature
would provide a big upwards compatibility for the kernel<->hypervisor
system. The case for this would be needing to forcefully upgrade the
hypervisor due to security issues and finding out that the hypervisor
is incompatible at the paravirtualizatrion level, then the user would
be at least capable of continuing to run the old kernel with the new
hypervisor until the compatibility is reached again.
BTW, what is the recommended distro or kernel setup to help testing
the latest paravirt patches? I've got a spare machine (with no needed
data) at hand which could be put to good use.
--
Greetz, Antonio Vargas aka winden of network
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
