lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 06 Mar 2007 18:35:38 -0800 From: Zachary Amsden <zach@...are.com> To: Chris Wright <chrisw@...s-sol.org>, Ingo Molnar <mingo@...e.hu> CC: Gerd Hoffmann <kraxel@...e.de>, virtualization <virtualization@...ts.osdl.org>, Jan Beulich <jbeulich@...ell.com>, Andrew Morton <akpm@...ux-foundation.org>, Linus Torvalds <torvalds@...ux-foundation.org>, linux-kernel@...r.kernel.org, Roland McGrath <roland@...hat.com> Subject: Re: Xen & VMI? Chris Wright wrote: > I agree that changing the interface to the low-level platform is tricky > and less isolated. But how does the VMI protect you from those changes? > It simply doesn't, the changes are still necessary. And the inflexibility > means the tough corner cases swept under the VMI rug are more difficult > to debug, get right, etc... > I actually disagree here. Yes, it will change over time. VMI was designed to be extensible and flexible - you can omit implementation for any calls you don't require, and with consensus, you can add new flags, fields, and calls where you need them. But VMI as it stands today is simply not sufficient to support the hypervisors which are here now. There are gaps, particularly with SMP support, which require significant changes to either the hypervisors, the kernel, or the VMI itself. There are many reasons these gaps still exist, but most prominently, the big reason is that nobody wanted to use a single ABI to interface to the hypervisor a year ago when we first proposed the VMI interface as a virtualization solution for Linux. In the end, I see no reason the technical issues can't be solved, but the larger questions about the future evolution of the interface and also some largely non-technical points, valid or not, have stalled the growth which we originally desired. At this point, the question of whether to pursue a common ABI is no longer a technical issue, it's no longer a management or evolutionary issue at all. It's a pragmatic issue about getting code that works into Linux today. It's about working together using what we have as a base, which is paravirt-ops, to get working code to users. We can always evolve the code in tree if we find a workable cross-vendor ABI that solves everyone's problems. But that is neither here nor there, because it isn't here today. Zach - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists