[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: A proposal - binary



Greg KH wrote:
On Thu, Aug 03, 2006 at 12:26:16PM -0700, Zachary Amsden 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 :)

I don't really think there's an issue to be skirted here. The current plan is to design and implement a paravirt_ops interface, which is a typical Linux source-level interface between the bulk of the kernel and a set of hypervisor-specific backends. Xen, VMWare and other interested parties are working together on this interface to make sure it meets everyone's needs (and if you have another hypervisor you'd like to support with this interface, we want to hear from you).

Until VMWare proposed VMI, Xen was the only hypervisor needing support, so it was reasonable that the Xen patches just go straight to Xen. But with paravirtops the result will be more flexible, since a kernel will be configurable to run on any combination of supported hypervisor or on bare hardware.

As far as I'm concerned, the issue of whether VMI has a stable ABI or not is one which on the VMI side of the paravirtops interface, and it doesn't have any wider implications.

Certainly Xen will maintain a backwards compatible hypervisor interface for as long as we want/need to, but that's a matter for our side of paravirtops. And the paravirtops interface will change over time as the kernel does, and the backends will be adapted to match, either using the same ABI to the underlying hypervisor, or an expanded one, or whatever; it doesn't matter as far as the rest of the kernel is concerned.

There's the other question of whether VMI is a suitable interface for Xen, making the whole paravirt_ops exercise redundant. Zach and VMWare are claiming to have a VMI binding to Xen which is full featured with good performance. That's an interesting claim, and I don't doubt that its somewhat true. However, they haven't released either code for this interface or detailed performance results, so its hard to evaluate. And with anything in this area, its always the details that matter: what tests, on what hardware, at what scale? Does VMI really expose all of Xen's features, or does it just use a bare-minimum subset to get things going? And how does the interface fit with short and long term design goals?

I don't think anybody is willing to answer these questions with any confidence. VMWare's initial VMI proposal was very geared towards their particular hypervisor architecture; it has been modified over time to be a little closer to Xen's model, in order to efficiently support the Xen binding. But Xen and ESX have very different designs and underlying philosophies, so I wouldn't expect a single interface to fit comfortably with either.

As far as LKML is concerned, the only interface which matters is the Linux -> <something> interface, which is defined within the scope of the Linux development process. That's what paravirt_ops is intended to be.

And being a Linux API, paravirt_ops can avoid duplicating other Linux interfaces. For example, VMI, like the Xen hypervisor interface, need various ways to deal with time. The rest of the kernel needn't know or care about those interfaces, because the paravirt backend for each can also register a clocksource, or use other kernel APIs to expose that interface (some of which we'll probably develop/expand over time as needed, but in the normal way kernel interfaces chance).

   J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.