[wellylug] Xen and Windows

[Daniel Pittman]

"Andrew Tarr" <andrewtarr at gmx.net> writes:
> Daniel Pittman <daniel at rimspace.net> wrote:
>
>> > *) paravirtualisatation is providing a virtual 'almost the real thing'
>> > environment.
>>  I think you mean "paravirtualization is *NOT* providing", or "normal
>> virtualization is providing" here...
>
> No, I meant to write what I wrote, and it seems right in my head, but I
> guess it wasn't clear enough because I think you think it means something
> different to what I meant it to mean :-]
>
> By 'almost the real thing' I mean that for example a paravirtual x86
> environment (such as what Xen provides on a hardware platform without
> hardware support for virtualization) doesn't implement the full x86
> instruction set (and may provide additional instructions), whereas a fully
> virtual x86 environment(like I believe VMWare can provide) implements all of
> the x86 instructions.

Ah!  No, not at all.  They both provide the same instruction set[1]; in fact,
if they didn't then software wouldn't work as expected.

The difference is how they deal with *hardware*.

Specifically, a paravirtualized system is one where there is no pretense of
hardware; the "guest" kernel talks to the (software) hypervisor through some
well defined software ABI.

A "pretend hardware" virtualized system, like Xen-with-Windows, or VMWare,
KVM, VirtualBox, or whatever, actually pretends that there is hardware
there[2].

So, one example would be handling interrupts: a paravirtual system calls the
hypervisor "do something with interrupts" API entry point.

A "pretend hardware" type system, on the other hand, talks to a pretend
APIC[3], which the hypervisor intercepts and does whatever the guest was
requesting.


The main differences, which are in truth pretty slim, between the two are:

1. You modify the paravirtual guest to know about the hypervisor ABI, not just
   the real hardware.

2. The paravirtual hypervisor ABI can, in some cases, be more efficient
   because the ABI can be defined in terms of the action, not in terms of
   manipulating hardware to perform the action.[4]

> One is 'almost the real thing' and the other is 'the real thing' in terms of
> being an implementation of the x86 instruction set.

In terms of peripheral hardware, rather than the instruction set.

> Obviously neither is the real thing in terms of actually being a piece of
> silicon that implements the x86 instruction set.

...and, generally, both run *most* of their instructions natively on the raw
hardware.  Emulating instructions is very, very slow, and the main point of
the VMX style extensions is to improve the speed of that emulation by doing
more work in hardware.

Regards,
        Daniel

Footnotes: 
[1]  Some will be run on hardware, some emulated, and some rejected, but the
     instructions themselves are identical.

[2]  ...for a while.  Then the paravirtualized drivers kick in, and replace
     most of the pretend hardware with paravirtual calls to the hypervisor, so
     you get pretty much the same performance benefits from this as from Xen.
     Just with more flexibility.

[3]  Advanced Programmable Interrupt Controlled.

[4]  OTOH, this is not necessarily true: the performance difference between a
     paravirtualized NIC and an emulated E1000 is fairly slim, if the emulated
     E1000 supports TSO and similar performance features.

-- 
✣ Daniel Pittman            ✉ daniel at rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons
   Looking for work?  Love Perl?  In Melbourne, Australia?  We are hiring.