Chris Wright wrote:
* Greg KH ([email protected]) wrote:
Who said that? Please smack them on the head with a broom. We are all
actively working on implementing Rusty's paravirt-ops proposal. It
makes the API vs ABI discussion moot, as it allow for both.
So everyone is still skirting the issue, oh great :)
No, we are working closely together on Rusty's paravirt ops proposal.
Given the number of questions I've fielded in the last 24 hrs, I really
don't think people understand this.
We are actively developing paravirt ops, we have a patch series that
begins to implement it (although it's still in it's nascent stage). If
anybody is interested in our work it is done in public. The working
tree is here: http://ozlabs.org/~rusty/paravirt/ (mercurial patchqueue,
just be forewarned that it's still quite early to be playing with it,
doesn't do much yet). We are using the virtualization mailing list for
discussions https://lists.osdl.org/mailman/listinfo/virtualization if
you are interested.
Zach (please correct me if I'm wrong here), is working on plugging the
VMI into the paravirt_ops interface. So his discussion of binary
interface issues is as a consumer of the paravirt_ops interface.
To be completely clear, I am creating a set of paravirt_ops for ESX.
This set of paravirt ops will still go through a binary indirection
layer. Hence, it is important for me to educate everyone on that layer
and find out the opinions people have on what an acceptable license /
source policy is for that layer. We need the layer for exactly the same
reason the vsyscall page is important. We use it to indirect
hypervisor calls so that they can be future compatible, instead of
forcing a particular hypervisor interface. When running on Intel vs.
AMD hardware, that interface may be different. When running inside HVM
hardware, VT or Pacifica, that interface _will_ be different. We must
allow for the possibility of alternative implementations. This layer is
very much like a PAL code layer that allows system level instructions to
have alternative implementations, and also, most importantly, means we
are free to change the structural layout of information which is shared
between the hypervisor and the kernel. This shared information will
grow and need to change as it evolves over time. But we can't break
compatibility with precompiled Linux kernels. So the layer needs to be
there and needs to be separate from the kernel, and I need to do that in
such a way that doesn't violate the licensing model of Linux or any
other operating system, while making sure that also doesn't conflict
with our corporate licensing policies. This is not a trivial problem.
So, in case it's not clear, we are all working together to get
paravirt_ops upstream. My personal intention is to do everything I can
to help get things in shape to queue for 2.6.19 inclusion, and having
confusion over our direction does not help with that agressive timeline.
Paravirt_ops has long term benefits for the i386 (and x86_64)
architectures. This is independent in fact of whether Xen and VMware
want to use the same ABI to talk to the hypervisor or not. From my
point of view, it is a cleaner way to implement the kernel backend to
both VMI and Xen, since it removes the requirement that we create an
entirely new sub-architecture for each hypervisor. In the Xen case,
they may want to run a dom-0 hypervisor which is compiled for an actual
hardware sub-arch, such as Summit or ES7000. Using a sub-arch for the
hypervisor means you would need some kind of nested sub-architecture
support. This is ludicrous. Instead, what paravirt-ops promises long
term is a way to get rid of the sub-architecture layer altogether.
Sub-arches like Voyager and Visual workstation have some strange
initialization requirements, interrupt controllers, and SMP handling.
Exactly the kind of thing which paravirt_ops is being designed to
indirect for hypervisors. In the end, there is no reason it can't be
expanded to a more general purpose interface that removes the
requirement to build separate kernels and maintain separate
sub-architectures for each weird new tweak of i386. As i386 moves into
more embedded systems, I would expect to see these new sub-architectures
begin to grow like a rash. It's ugly, and hard to maintain. I've
broken SGI Visual workstation and Voyager support more than I'd care to
admit because it is really hard to compile and test all of these
different variations of i386. In the end, it will finally be possible
to compile and run a single i386 kernel binary that is actually capable
of running on the full set of supported hardware. This makes every
distro and maintainers life a lot simpler.
The same approach can be used on x86_64 for paravirtualization, but also
to abstract out vendor differences between platforms. Opteron and EMT64
hardware are quite different, and the plethora of non-standard
motherboards and uses have already intruded into the kernel. Having a
clean interface to encapsulate these changes is also desirable here, and
once we've nailed down a final approach to achieving this for i386, it
makes sense to do x86_64 as well.
I'm now talking lightyears into the future, but when the i386 and x86_64
trees merge together, this layer will be almost identical for the two,
allowing sharing of tricky pieces of code, like the APIC and IO-APIC,
NMI handling, system profiling, and power management. It the interface
evolves in a nicely packaged and compartmentalized way from that, then
perhaps someday it can grow to become a true cross-architecture way to
handle machine abstraction and virtualization. Then you can compile a
single kernel which gets assembled to code proto-fragments that are
dynamically linked together during the boot sequence, using a
cross-machine translation unit that allows a single kernel to run on
every current and future processor architecture that mimics some
combined set of machine characteristics (N-tiered cache coloring,
multiway hardware page tables, hypercubic interrupt routing, dynamically
morphed GPUs, quantum hypervisor isolation). Of course, it will still
require a PCI bus.
So absolutely we should go in that direction now, and I'm fully
committed to working on it. Which is why I wanted feedback on what we
have to do to make sure our ESX implementation is done in a way that is
acceptable to the community. I too would like to push for an interface
in 2.6.19, and we can't have confusion on this issue be a last minute
stopper.
Maybe someday Xen and VMware can share the same ABI interface and both
use a VMI like layer. But that really is a separate and completely
orthogonal question. Paravirt-ops makes any approach to integrating
hypervisor awareness into the kernel cleaner by providing an appropriate
abstract interface for it.
Zach
-
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]
