![]() | |||||||||||
Messages in this thread |
On Thu, 03 Aug 2006 19:52:40 -0700 Jeremy Fitzhardinge <jeremy@xensource.com> wrote: > 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 :) > > A reasonable summary. A few touchups: > 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. No, even if vmware wasn't on the scene, the proposal to make the Linux->hypervisor interface be specific to one hypervisor implementation is a concern. That would remain true if vmware were to suddenly vanish. It is a major interface, and interfaces are a major issue. > 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. That was a major goofup from a kernel-development-process POV. They're working hard to get that code out to us. > 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? This is a key issue and to some extent all bets are off until that code emerges. Because it could be that the VMI->Xen implementation works well, and that any present shortcomings can be resolved with acceptable effort. If that happens, it puts a cloud over paravirtops. But we just don't know any of this until we can get that code into the right people's hands. > 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. Maybe, maybe not. Until we have an implementation to poke at this is all speculation. And it is most regrettable that we're being put in a position where we are forced to speculate. > 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. 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. > 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). > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||
| Last update: 2006-08-04 06:23 [from the cache] ©2003-2008 | |||||||||||