linux-kernel - RE: Xen & VMI?

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8FFF7E42E93CC646B632AB40643802A80229779B@scsmsx412.amr.corp.intel.com>
Date:	Tue, 6 Mar 2007 09:17:39 -0800
From:	"Nakajima, Jun" <jun.nakajima@...el.com>
To:	"Anthony Liguori" <anthony@...emonkey.ws>,
	"Ingo Molnar" <mingo@...e.hu>
Cc:	"virtualization" <virtualization@...ts.osdl.org>,
	"Roland McGrath" <roland@...hat.com>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Jan Beulich" <jbeulich@...ell.com>, <linux-kernel@...r.kernel.org>
Subject: RE: Xen & VMI?

Anthony Liguori wrote:
> Ingo Molnar wrote:
>> * Gerd Hoffmann <kraxel@...e.de> wrote:
>> 
>>>>> 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.
>>> Fine, so lets move kvm paravirtualitzation into vmi too (proof of
>>> concept code by Anthony Liguori exists) and kill one more item on
>>> the (linux) QA test matrix?  (just following your arguments, not
>>> that I'm confident it would actually help reducing QA effort).
>> 
>> yes - although obviously a KVM Linux guest does not need such an
>> interface - but it's a nice proof of concept to integrate other guest
>> OSs into KVM.
> 
> I disagree that a KVM Linux guest does not benefit from VMI.  Right
> now, your KVM paravirt interface only covers CR3 target caching and
> apic enhancements (neither of which I believe have made it into
> 2.6.21). Inevitably, things like MMU batching will be added.

I think a KVM Linux would benefit more from paravirt ops, rather than
VMI. The higher-level interface such as the one in Xen, espeically for
I/O, interrupt controllers, timer, SMP, etc. actually simplifies the
implementation of the VMM, and improve performance of the guest. Even
for MMU, direct page tables, for example, would work better for
hardware-based virtualization because the processor can use the native
page tables. 

> 
> Using paravirt_ops, this is going to require new kernels for the
>   guests. Every new paravirtualization feature will require a new
>   guest kernel. With VMI, one can add these features to any 2.6.21+
> guest by just modifying the ROM (assuming a newer host).  Some
> features will require new VMI entry points but quite a lot will fall
> under the current entry points.
> 
> Of all the hypervisors, KVM is the easiest to use VMI with.  QEMU
> already supports option ROM loading and Zach just made some changes to
> allow a native ROM to be implemented very easily.
> 
> If we're going to use VMI for anything other than VMware, it seems to
> be that KVM should be what we use it for.
> 
> Regards,
> 
> Anthony Liguori
> 
>> 	Ingo
> 

Jun
---
Intel Open Source Technology Center
-
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/