[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Al Boldi" <a1426z@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
  • Date: Tue, 8 Aug 2006 11:20:00 +0200
  • Delivery-date: Tue, 08 Aug 2006 02:20:39 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Aca6yYZ8d/UvuZVxQMaxeWTPV8UFyAAADfyQ
  • Thread-topic: [Xen-devel] Questioning the Xen Design of the VMM

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Al Boldi
> Sent: 07 August 2006 16:01
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] Questioning the Xen Design of the VMM
> 
> Greetings!
> 
> The Xen project caught my attention on LKML discussing 
> hypervisors, so I took 
> a look at Xen and read the README, where it says:
> 
>       This install tree contains source for a Linux 2.6 guest
> 
> This immediately turned me off, as I hoped Xen would be a bit more 
> transparent, by simply exposing native hw tunneled thru some 
> multiplexed Xen 
> patched host-kernel driver.

The actual hardware isn't exposed to the guest at all [unless you
explicitly ask for it in the configuration]. There are drivers that are
virtual versions of the real hardware, but there is no way that the
guest OS is ever touching any network or hard-disk, unless you've
explicitly configured it so - and then it uses a driver that is the
native driver [with some minor modifications to deal with the
virtualization - those modifications are generally in header files (at
least for well-behaved drivers)]. 

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...

> 
> 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. 

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. 

I hope this is of use to you. 

Please feel free to ask any further questions... 

--
Mats

> 
> 
> Thanks!
> 
> --
> Al
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.