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

[Al Boldi <a1426z@xxxxxxxxx>]

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?


Thanks!

--
Al


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