Self-virtualizable x86 processors?

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

A recent news article about a virtual-machine software pakage

<http://www.crn.com/nl/crndirect/showArticle.jhtml?articleId=54201647>

implied that both Intel and AMD are considering self-virtualizable
versions of the x86 architecture.

... the debut of virtualization features in next-generation CPUs
from Intel and AMD will make it easier to support unmodified
operating systems, ... [AFAIK, in such CPUs, all mode-sensitive
and/or location-sensitive x86 instructions would have to be made
privileged, i.e., to trap when executed in user mode.]

Does anybody know whether or when such CPUs might be expected to hit
the market?

Note: I realize that the article did not explicitly mention "x86
architectures", but various other architectures (e.g., the IA64) are
already self virtualizable, so the quote conveys a misimpression
unless it refers to x86-based instruction sets.

Thanks,
Tom Payne

 

[keith]

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Mon, 20 Dec 2004 14:27:55 +0000, Tom Payne wrote:

> A recent news article about a virtual-machine software pakage
>
> <http://www.crn.com/nl/crndirect/showArticle.jhtml?articleId=54201647>
>
> implied that both Intel and AMD are considering self-virtualizable
> versions of the x86 architecture.
>
> ... the debut of virtualization features in next-generation CPUs
> from Intel and AMD will make it easier to support unmodified
> operating systems, ... [AFAIK, in such CPUs, all mode-sensitive
> and/or location-sensitive x86 instructions would have to be made
> privileged, i.e., to trap when executed in user mode.]

That's pretty much what's required, though this new "priveleged state" has
to be on top of the current ISA's privelege structure to maintain
compatability. The rest is a SMOP. ;-)

> Does anybody know whether or when such CPUs might be expected to hit the
> market?

> Note: I realize that the article did not explicitly mention "x86
> architectures", but various other architectures (e.g., the IA64) are
> already self virtualizable, so the quote conveys a misimpression unless
> it refers to x86-based instruction sets.

It's amazing that it's taken this long for x86 to grow a hypervisor. As
you point out, this has been done <many times> before. Though there is a
certain group Washington (and I don't mean three-letter government
agencies) would not like to see themselves virtualized out of existence.
I'd love to have multiple OSs running along side each other.

--
Keith


>
> Thanks,
> Tom Payne

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

keith wrote:

>>Note: I realize that the article did not explicitly mention "x86
>>architectures", but various other architectures (e.g., the IA64) are
>>already self virtualizable, so the quote conveys a misimpression unless
>>it refers to x86-based instruction sets.
>
>
> It's amazing that it's taken this long for x86 to grow a hypervisor. As
> you point out, this has been done <many times> before. Though there is a
> certain group Washington (and I don't mean three-letter government
> agencies) would not like to see themselves virtualized out of existence.
> I'd love to have multiple OSs running along side each other.

Well, back in the late 80's, Intel actually created a Hypervisor layer
for x86 real mode, called Virtual-86.

Yousuf Khan

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

keith wrote:
>
> I'd love to have multiple OSs running along side each other.
>

You already can do that - sort of - with your new Opty system.
http://www.vmware.com/products/desktop/ws_features.html

I haven't tried VMWare 4 or 4.5 yet, but I did use 3.0 for
half a year at one place I worked. I used W2K as the "host"
OS, and ran additional copies of W2K, XP, NT, WinMe, Win9x,
and Linux in virtual machines.

Price has come down a lot too. Used to be $300 for the
workstation version, but is currently $189.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

Tom Payne wrote:

> A recent news article about a virtual-machine software package
> implied that both Intel and AMD are considering self-virtualizable
> versions of the x86 architecture.
>
> ... the debut of virtualization features in next-generation CPUs
> from Intel and AMD will make it easier to support unmodified
> operating systems, ... [AFAIK, in such CPUs, all mode-sensitive
> and/or location-sensitive x86 instructions would have to be made
> privileged, i.e., to trap when executed in user mode.]
>
> Does anybody know whether or when such CPUs might be expected to hit
> the market?

Vanderpool, Silvervale to Intel. Pacifica to AMD.

http://www.xbitlabs.com/news/cpu/display/20040912113927.html

AFAIU, Pacifica is not expected before 2006 :-(

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

keith <krw@att.bizzzz> wrote:
> On Mon, 20 Dec 2004 14:27:55 +0000, Tom Payne wrote:
>
>> A recent news article about a virtual-machine software pakage
>>
>> <http://www.crn.com/nl/crndirect/showArticle.jhtml?articleId=54201647>
>>
>> implied that both Intel and AMD are considering self-virtualizable
>> versions of the x86 architecture.
>>
>> ... the debut of virtualization features in next-generation CPUs
>> from Intel and AMD will make it easier to support unmodified
>> operating systems, ... [AFAIK, in such CPUs, all mode-sensitive
>> and/or location-sensitive x86 instructions would have to be made
>> privileged, i.e., to trap when executed in user mode.]
>
> That's pretty much what's required, though this new "priveleged state" has
> to be on top of the current ISA's privelege structure to maintain
> compatability.

Hmmmm. I don't see that trapping and virtualizing privileged
instructions would seem to be a *reuse* of an existing privilege
level.

> The rest is a SMOP. ;-)

That programming can be simplified via host OSes that provide
restricted user-mode access to page tables.

>> Does anybody know whether or when such CPUs might be expected to hit the
>> market?
>
>> Note: I realize that the article did not explicitly mention "x86
>> architectures", but various other architectures (e.g., the IA64) are
>> already self virtualizable, so the quote conveys a misimpression unless
>> it refers to x86-based instruction sets.

> It's amazing that it's taken this long for x86 to grow a hypervisor.

Exactly. How hard can it be to make half-a-dozen
sensitive-but-unprivileged instruction trap when executed in user
mode? Handlers could be provided to hide the fact that they trapped
at all by emulating current behavior. However, the benefits begin
when you have handlers that virtualize all privileged instructions.

> As you point out, this has been done <many times> before. Though
> there is a certain group Washington (and I don't mean three-letter
> government agencies) would not like to see themselves virtualized
> out of existence.

In fact, virtualization could be a cleaner way for them to provide
backward compatibility within their OS family. Currently, each step
forward is hindered by questions of which applications not to break.

Regards,
Tom Payne

 

[keith]

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Mon, 20 Dec 2004 13:03:08 -0500, Yousuf Khan wrote:

> keith wrote:
>
>>>Note: I realize that the article did not explicitly mention "x86
>>>architectures", but various other architectures (e.g., the IA64) are
>>>already self virtualizable, so the quote conveys a misimpression unless
>>>it refers to x86-based instruction sets.
>>
>>
>> It's amazing that it's taken this long for x86 to grow a hypervisor. As
>> you point out, this has been done <many times> before. Though there is a
>> certain group Washington (and I don't mean three-letter government
>> agencies) would not like to see themselves virtualized out of existence.
>> I'd love to have multiple OSs running along side each other.
>
> Well, back in the late 80's, Intel actually created a Hypervisor layer
> for x86 real mode, called Virtual-86.

True, though we'd still be stuck with 8086 DOS if they kept that
virtualization. I was thinking of a complete self-virtualization like the
S370. IIRC a S370 can completely virtualize itself. If it's done like
the PowerPC's (or V86s) virtualization, BillyG's malware will simply
take over as hypervisor. ;-)

--
Keith

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

Grumble wrote:
> Vanderpool, Silvervale to Intel. Pacifica to AMD.

Right, see also

http://groups-beta.google.com/group/comp.arch/browse_thread/thread/8d1df82fe6323ee7?tvc=2&q=vanderpool+intel

> Tom Payne wrote:
> > Does anybody know whether or when such CPUs might be expected to
hit
> > the market?

At the Fall 2004 Intel Developer Forum (IDF), Intel announced "VT"
(Virtualization Technolgy) to become available when Windows Longhorn
will be available (unfortunately, they apparently removed the session
video from their web site already). So that will AFAIK be some time in
2006
(http://www.microsoft.com/presspass/press/2004/Aug04/08-27Target2006PR.asp).

VT allows a CPU to be "partitioned". From what I understand, each CPU
partition supports a full virtual machine, which is completeley
isolated from all the other partitions. Much like Virtual PC and VMware
allow already today.

However, virtualization of the x86 in software (VPC/VMware) requires a
lot of overhead. That's mainly because some x86 privileged information
can be requested from all privilege levels without raising an exception
(e.g. the CPU's current privilege level).

There's a very interesting video of a session held at the stanford
university, where VMware's chief developer explains how virtualization
is done for x86 in software. I currently don't have the URL handy but I
can find that again if anyone's interested.

Stephan
All speaking for myself.
Visit my profile page at Microsoft:
http://www.microsoft.com/whdc/resources/mvp/SW-MVP.mspx

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

keith <krw@att.bizzzz> wrote:
[...]
> I was thinking of a complete self-virtualization like the S370.

Me too.

> IIRC a S370 can completely virtualize itself.

Right.

Today, I found a paper that analyzes the x86 instruction set for
barriers to self-virtualizability:

<http://www.cs.nps.navy.mil/people/faculty/irvine/publications/2000/VMM-usenix00-0611.pdf>

The authors identify 17 of the roughly 250 x86 instructions as
hindering self-virtualizability. Specifically, these instructions
are:

1) SENSITIVE: They allow a guest operating system to determine that
it's not in control -- they can let the virtualization cat out of
the bag. More specifically, they behave differently depending on
the protection mode and/or the memory-control settings.

2) NONPRIVILEGED: They don't trap when executed at protection level
zero, so they can't be faked by the host operating system to
keep the virtualization cat in the bag.

So, why can't AMD and/or Intel simply appropriate an unused bit in
some protected register to control "virtualization mode"? (These 17
instructions would then trap when and only when the protection level
is nonzero and that bit is set.)

Tom Payne

 

[keith]

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Sun, 26 Dec 2004 13:40:55 +0000, Tom Payne wrote:

> keith <krw@att.bizzzz> wrote:
> [...]
>> I was thinking of a complete self-virtualization like the S370.
>
> Me too.
>
>> IIRC a S370 can completely virtualize itself.
>
> Right.
>
> Today, I found a paper that analyzes the x86 instruction set for
> barriers to self-virtualizability:
>
> <http://www.cs.nps.navy.mil/people/faculty/irvine/publications/2000/VMM-usenix00-0611.pdf>
>
> The authors identify 17 of the roughly 250 x86 instructions as
> hindering self-virtualizability. Specifically, these instructions
> are:
>
> 1) SENSITIVE: They allow a guest operating system to determine that
> it's not in control -- they can let the virtualization cat out of
> the bag. More specifically, they behave differently depending on
> the protection mode and/or the memory-control settings.
>
> 2) NONPRIVILEGED: They don't trap when executed at protection level
> zero, so they can't be faked by the host operating system to
> keep the virtualization cat in the bag.
>
> So, why can't AMD and/or Intel simply appropriate an unused bit in
> some protected register to control "virtualization mode"? (These 17
> instructions would then trap when and only when the protection level
> is nonzero and that bit is set.)

That's essentially the way the Power4/970 processor works. MSR[HV]
controls the hypervisor state (MSR[PR] is the priveleged state). The only
way into HV state is an exception, returning restores the state. I'm
certainly not a processor architect, but I don't think this is quite the
same as S/370's self virtualization, where VM370 (or whatever it's called
these days) will fully well run under VM/370, in all its glory.

--
Keith

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

Tom Payne wrote:
> So, why can't AMD and/or Intel simply appropriate an unused bit in
> some protected register to control "virtualization mode"? (These 17
> instructions would then trap when and only when the protection level
> is nonzero and that bit is set.)

I think both of them are working on hardware-based virtualization
techniques. It's called Pacifica in the case of AMD, and VT in the case
of Intel.

Yousuf Khan