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>, Daniel Stodden <stodden@xxxxxxxxxx>
Subject: Re: [Xen-devel] Questioning the Xen Design of the VMM
From: Al Boldi <a1426z@xxxxxxxxx>
Date: Thu, 10 Aug 2006 17:55:11 +0300
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 11 Aug 2006 03:40:45 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <907625E08839C4409CE5768403633E0BA7FE18@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: <907625E08839C4409CE5768403633E0BA7FE18@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.5
Petersson, Mats wrote:
> > Al Boldi wrote:
> > You mean AMDV/IntelVT extensions?
> Yes.
> > If so, then these extensions don't actively participate in the act of
> > virtualization, but rather fix some x86-arch shortcomings, that make it
> > easier for software (i.e. Xen) to virtualize, thus circumventing the need
> > to do binary translation.  Is this a correct reading?
> Not sure what your exact meaning is here.
> What do you mean by "actively participate in the act of virtualization".

Is there any logic involved, that does some kind of a translation/control?

It seems not.

Daniel Stodden wrote:
> they fix the issues, removing the general need for binary translation,
> but go well beyond that as well.
> a comparatively simple example of where it goes beyond are privilege
> levels. basic system virtualization would just move the guest kernel to
> a nonprivileged level to maintain control in the vmm. so you'd have the
> hypervisor in supervisor mode (that's why it's called a hypervisor), and
> both guest kernel and applications in user mode [1]. [should note that
> xen makes a difference here, using x86 privilege levels which are more
> complex].
> what vtx does is keeping the privilege rings in protected mode untouched
> by the virtualization features. instead, two whole new modes are added:
> 'vmx root' and 'vmx non-root'. the former applies to the vmm, the latter
> to the guests. _both_ of these basically implement the protected mode as
> it used to be. so hardware virtualization won't have to muck around with
> the regular privilege system.
> one example where this is particularly useful are hosted vmms, e.g.
> vmware workstation. imagine a natively-running operating system and a
> machine monitor running on top of (or integrated with) that. the system
> would run in vmx-root mode. regular application processes there in ring3
> as they used to. additionally, one may start guest systems on top of the
> vmm, which again are implemented on top a regular x86 protected mode,
> but in non-root mode.
> all of the above
>  - can be functionally achieved _efficiently_ without hardware
>    extensions like vmx
>  - but ONLY as long as the privilege architecture supports
>    virtualization
>  - x86 does NOT [2]
>    the pushf/popf outlined is an example of where the problems are
>    - binary translation is a way to do it anyway, but does not count
>      as 'efficient'.
> with vmx
>   - efficient virtualization is achieved.
>   - some things just get additional flexibility.

So VMX doesn't really virtualize anything, but rather enables software to 
perform virtualization more efficiently.

Petersson, Mats wrote:
> There is no doubt that para-virtualization is one viable solution to the
> virtualization problem, but it's not the ONLY solution. Each user has a
> choice: Recompile and get performance, or run unmodified code at lower
> performance.

Agreed, but how much lower performance are we talking about in an HVM vs 
para-virtualized scenario?



Xen-devel mailing list