* Gerd Hoffmann <kraxel at suse.de> wrote: > > cleanliness and performance: KVM doesnt need any artificial > > indirection. > > Xen doesn't need it either. > > > IMO the GPL-ed ROM portion of VMI was a bad idea to begin with. > > So why do you want xen use vmi then? due to the other argument i listed: || Also, lguest and KVM is Linux-internal, so there's a natural match || between the guest and the host APIs. It's a basic kernel maintainance issue: lguest/KVM and Linux host and guest will co-evolve foward in a natural way as they are in essence Linux-internal technologies. They /will/ harmonize. There is no such guarantee with Xen/VMWare/etc. (which are distinctly separate technologies) - so any ABIs towards them could become (and are already becoming) a drag and distraction. > > well, the VMI patches got into Linux with the claim that it's also > > useful for Xen. So that claim was ... not actually true? > > As mentioned there was a proof-of-concept VMI ROM done by vmware. As > far I know it translated the VMI ROM interface calls into xen > hypercalls somehow, Zach probably has more details. > > So in the end you would still have two different hypervisor ABI's, the > VMI ROM just hides that. oh, but that way i have cleverly pushed the problem out of Linux and into the VMI-ROM's domain ;) Which is all i care about. really, one of my jobs as a maintainer is to keep crap out of Linux (we are capable of adding enough crap ourselves ;-). Having multiple, overlapping, technologically redundant ABIs between /software/, embedded into the heart of the kernel (paravirt ops nonwithstanding), for perpetuity, is one such type of crap. It is in fact the kind of crap i'm /most/ worried about, because it sticks forever. Ingo
