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 > <[email protected] <mailto:[email protected]>> 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 > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > On Mon, Jun 18, 2012 at 5:51 PM, Ribhi Kamal > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> 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 > > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > https://www.virtualbox.org/mailman/listinfo/vbox-dev > > > > > > > > > > -- > > -- Ribhi > > > > > > _______________________________________________ > > vbox-dev mailing list > > [email protected] <mailto:[email protected]> > > 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 > [email protected] <mailto:[email protected]> > 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 _______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
