[vbox-dev] 386, 486 or 686?

Klaus Espenlaub klaus.espenlaub at oracle.com
Mon Jun 18 17:46:40 GMT 2012 

On 18.06.2012 19:20, Ribhi Kamal wrote:
> Klaus,
> I understand your frustration, but I think you misread my question. I
> wasn't asking if the vbox emulates instructions that are not supported
> by the host CPU, I was asking if the number of instructions on 386 vs.
> 686 which require workarounds (i.e patch manager) is different.

You still didn't answer the question, which means that any answer is 
making uneducated guesses and probably wrong assumptions. The patch 
manager is active for raw mode (i.e. with software virtualization), 
which is becoming less relevant the more CPUs are shipped with hardware 
virtualization support. In any case, the new instructions are usually 
better designed, so are either completely non-critical, or cause a trap 
anyway. So no unnecessary inefficiency or patching.

> Assuming that 386 has less problematic instructions than 686, I should
> be able to get an improved performance if I compile the Linux kernel to
> target 386.

Your assumption is very wrong. The 386 was a quick'n'dirty design to 
make money after the iAPX432 disaster (yes, Intel originally wanted to 
change the world, which has some similarity to the Itanium). Modern CPUs 
are far more efficient, and OSes compiled for those CPUs actually use 
those more efficient instructions, effectively becoming more 
virtialization friendly.

I don't think it makes any sense to continue with this thread which is 
based on wrong assumptions, speculation, FUD and lack of information. 
I'm out of it in any case.

Klaus

>
>
> On Mon, Jun 18, 2012 at 12:36 PM, Klaus Espenlaub
> <klaus.espenlaub at oracle.com <mailto:klaus.espenlaub at oracle.com>> wrote:
>
>     On 18.06.2012 17:56, Ribhi Kamal wrote:
>      > I'm worried that some of these relatively new instructions might add
>      > more instructions that are troublesome to virtualize. So I'm
>     inclined to
>      > using the arch with the smallest feature set, 386, rather than
>     686. Does
>      > that sound right?
>
>     You expect detailed answers without giving the minimal set of facts -
>     what virtualization mode are you talking about? VirtualBoxe effectively
>     has 3 of them - the recompiler, raw mode and hardware virtualization. In
>     the last two effectively all "normal" instructions are executed usually
>     without significant overhead (ignoring interrupts/faults or unrelated
>     instructions which need attention by the hypervisor). In general,
>     VirtualBox tries to stay as much as possible in those two virtualization
>     modes (if available - there are conditions which may force going to the
>     recompiler).
>
>     In any case, VirtualBox doesn't offer instructions which the host CPU
>     doesn't have (and actually might disable the CPUID feature bits for some
>     instruction set extensions which the CPU might have), and thus there is
>     no need for completely emulating something in software (the recompiler
>     often does it nevertheless, just to have everything under control).
>
>     So don't worry too much about those fuzzy "relatively new instructions".
>
>     Klaus
>
>      > On Mon, Jun 18, 2012 at 10:58 AM, Alexey Eromenko
>     <al4321 at gmail.com <mailto:al4321 at gmail.com>
>      > <mailto:al4321 at gmail.com <mailto:al4321 at gmail.com>>> wrote:
>      >
>      >     On Mon, Jun 18, 2012 at 5:51 PM, Ribhi Kamal
>     <rbhkamal at gmail.com <mailto:rbhkamal at gmail.com>
>      > <mailto:rbhkamal at gmail.com <mailto:rbhkamal at gmail.com>>> wrote:
>      > > >From a Virtualbox point of view, would a Linux kernel be
>      >     easier/faster
>      > > to virtualize if it was targeted for a 386 CPU architecture, 486
>      >     or 686?
>      > > Would it make a difference at all?
>      >
>      >     I think 686 would be faster, as more instructions are available
>      >     (MMX, cmov, ...)
>      >
>      >     --
>      >     -Alexey Eromenko "Technologov"
>      >
>      >     _______________________________________________
>      >     vbox-dev mailing list
>      > vbox-dev at virtualbox.org <mailto:vbox-dev at virtualbox.org>
>     <mailto:vbox-dev at virtualbox.org <mailto:vbox-dev at virtualbox.org>>
>      > https://www.virtualbox.org/mailman/listinfo/vbox-dev
>      >
>      >
>      >
>      >
>      > --
>      > -- Ribhi
>      >
>      >
>      > _______________________________________________
>      > vbox-dev mailing list
>      > vbox-dev at virtualbox.org <mailto:vbox-dev at virtualbox.org>
>      > https://www.virtualbox.org/mailman/listinfo/vbox-dev
>
>
>     --
>     Oracle <http://www.oracle.com>
>     Dr. Klaus Espenlaub | Snr. Manager Software Development Desktop
>     Virtualization
>     Phone: +49 7151 60405 205 <tel:%2B49%207151%2060405%20205>
>     <tel:+49715160405205 <tel:%2B49715160405205>>
>     Oracle VM VirtualBox
>
>     ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | 71384 Weinstadt
>
>     ORACLE Deutschland B.V. & Co. KG
>     Hauptverwaltung: Riesstr. 25, D-80992 München
>     Registergericht: Amtsgericht München, HRA 95603
>     Geschäftsführer: Jürgen Kunz
>
>     Komplementärin: ORACLE Deutschland Verwaltung B.V.
>     Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
>     Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
>     Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
>
>     Green Oracle <http://www.oracle.com/commitment>         Oracle is
>     committed to
>     developing practices and products that help protect the environment
>
>
>     _______________________________________________
>     vbox-dev mailing list
>     vbox-dev at virtualbox.org <mailto:vbox-dev at virtualbox.org>
>     https://www.virtualbox.org/mailman/listinfo/vbox-dev
>
>
>
>
> --
> -- Ribhi


-- 
Oracle <http://www.oracle.com>
Dr. Klaus Espenlaub | Snr. Manager Software Development Desktop
Virtualization
Phone: +49 7151 60405 205 <tel:+49715160405205>
Oracle VM VirtualBox

ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | 71384 Weinstadt

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Geschäftsführer: Jürgen Kunz

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher

Green Oracle <http://www.oracle.com/commitment> 	Oracle is committed to
developing practices and products that help protect the environment

More information about the vbox-dev mailing list