This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Questioning the Xen Design of the VMM

To: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Subject: Re: [Xen-devel] Questioning the Xen Design of the VMM
From: Al Boldi <a1426z@xxxxxxxxx>
Date: Tue, 8 Aug 2006 17:10:28 +0300
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 09 Aug 2006 02:47:37 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <907625E08839C4409CE5768403633E0BA7FE0B@xxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <907625E08839C4409CE5768403633E0BA7FE0B@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.5
Petersson, Mats wrote:
> Al Boldi wrote:
> > I hoped Xen would be a bit more
> > transparent, by simply exposing native hw tunneled thru some
> > multiplexed Xen patched host-kernel driver.
> On the other hand, to reduce the size of the actual hypervisor (VMM),
> the approach of Xen is to use Linux as a driver-domain (commonly
> combined as the management "domain" of Dom0). This means that Xen
> hypervisor itself can be driver-less, but of course also relies on
> having another OS on top of itself to make up for this. Currently Linux
> is the only available option for a driver-domain, but there's nothing in
> the interface between Xen and the driver domain that says it HAS to be
> so - it's just much easier to do with a well-known, open-source,
> driver-rich kernel, than with a closed-source or driver-poor kernel...

Ok, you are probably describing the state of the host-kernel, which I agree 
needs to be patched for performance reasons.

> > I maybe missing something, but why should the Xen-design
> > require the guest to be patched?
> There are two flavours of Xen guests:
> Para-virtual guests. Those are patched kernels, and have (in past
> versions of Xen) been implemented for Linux 2.4, Linux 2.6, Windows,
> <some version of>BSD and perhaps other versions that I don't know of.
> Current Xen is "Linux only" supplied with the Xen kernel. Other kernels
> are being worked on.

This is the part I am questioning.

> HVM guests. These are fully virtualized guests, where the guest contains
> the same binary as you would use on a non-virtual system. You can run
> Windows or Linux, or most other OS's on this. It does require "new"
> hardware that has virtualization support in hardware (AMD's AMDV (SVM)
> or Intel VT) to use this flavour of guest though, so the older model is
> still maintained.

So HVM solves the problem, but why can't this layer be implemented in 

I'm sure there can't be a performance issue, as this virtualization doesn't 
occur on the physical resource level, but is (should be) rather implemented 
as some sort of a multiplexed routing algorithm, I think :)

> I hope this is of use to you.
> Please feel free to ask any further questions...

Thanks a lot for your detailed response!


Xen-devel mailing list