Is there any papers or projects proposing or fulfilling a type 1 hypervisor using binary translation to support OS compiled for different architecture?
Related
It's now quite common for embedded systems to run Linux on MIPS or PowerPC processors.
How well do Scala programs run on such systems ?
Obviously Scala requires a JVM - are good JVMs available on MIPS and PowerPC ?
In particular are there JVMs that support JIT or AOT compilation ?
Are there any requirements beyond a JVM, the standard JRE library, and the Scala library ?
Thanks in advance,
Nick.
JamVM has full support for the Java Virtual Machine Specification Java SE 8 Edition on both Linux/MIPS and Linux/PowerPC. It is purely a JVM, in order for it to be actually useful, you need to pair it with a JRE. JamVM supports both GNU Classpath as well as the OpenJDK 6, 7, and 8 class libraries. It can also be used as a JVM inside IcedTea. It has an inline-threaded interpreter with stack caching that can give performance comparable to a simple JIT compiler, but it cannot compete with sophisticated high-performance JIT compilers such as HotSpot C2, Oracle JRockit, or IBM J9.
Chinese MIPS CPU vendor open-sourced an OpenJDK 8 port to MIPS two weeks ago.
The IBM J9 JDK naturally has support for Linux/PowerPC. Or actually rather for Linux/POWER.
A company named MicroDoc sells a MIPS port of Oracle Java SE Embedded 8 and a PowerPC port. I don't believe Scala runs on Java SE Embedded, though.
What is the distinction between emulation and Full Virtualization, also called Hardware-assisted virtualizion (HVM)?
From this source, it is not clear what the relationship is.
Full Virtualization or Hardware-assisted virtualizion (HVM) uses
virtualization extensions from the host CPU to virtualize guests. HVM
requires Intel VT or AMD-V hardware extensions. The Xen Project
software uses Qemu to emulate PC hardware, including BIOS, IDE disk
controller, VGA graphic adapter, USB controller, network adapter etc.
Virtualization hardware extensions are used to boost performance of
the emulation. Fully virtualized guests do not require any kernel
support. This means that Windows operating systems can be used as a
Xen Project HVM guest. Fully virtualized guests are usually slower
than paravirtualized guests, because of the required emulation.
Source: Xen Project Wiki
In the following book these terms are considered synonymous.
At one extreme you have full virtualization, or emulation, in which
the virtual machine is a software simulation of hardware, real or
fictional — as long as there’s a driver, it doesn’t matter much.
Products in this category include VMware and QEMU.
Source: The book of Xen
Following are the excerpts from an article describing the actual difference between emulation and HWM. However, the only distinction I can see is, that virtualization enables to create more than one computing environment.
If emulation takes such a toll, why bother? Because we might want to
do one of the following:
Run an OS on a hardware platform for which it was not designed.
Run an application on a device other than the one it was developed for (e.g., run a Windows program on a Mac).
Read data that was written onto storage media by a device we no longer have or that no longer works.
Source: Russell Kay
Virtual machines offer the following advantages:
They're compatible with all Intel x86 computers.
They're isolated from one another, just as if they were physically separate.
Each is a complete, encapsulated computing environment.
They're essentially independent of the underlying hardware.
They're created using existing hardware.
Source: Russell Kay
There is another article, which only supports my hypothesis.
Emulation, in short, involves making one system imitate another. For
example, if a piece of software runs on system A and not on system B,
we make system B “emulate” the working of system A. The software then
runs on an emulation of system A.
In this same example, virtualization would involve taking system A and
splitting it into two servers, B and C.
So lets consider B=C and we have emulation, dont we?
Please note that virtualization is achieved by emulating the hardware components network adapters, USB, hard disk, CD drives etc in software. Thus emulation actually helps achieving virtualization.
Full virtualization is the technique of virtualization in which the guest OS runs unmodified, that is, the guest is not aware of whether it is running in a virtual machine environment or on a physical machine. Initially binary translation of the guest code was done in order to achieve full virtualization, but it wasn't good from performance perspective.
Para virtualization is a technique which requires modifications in the guest Operating System in order to gain better performance.
Hardware assisted virtualization is full virtualization technique as the guest Operating System runs unmodified. It is called hardware assisted because this type of virtualization utilizes virutalization specific extensions in host hardware like Intel-vtx, AMD-V etc. This technique not only offers full virtualization (guest OS does not require modification) but also has performance benefits and major vendors like Intel and AMD are providing extensions in hardware to support virtualization.
I recently have acquired a Apple G5 computer (PPC 970) and am interested in learning more about the PowerPC architecture (most of my systems programming knowledge comes from x86 and my own hobby kernel).
After using the computer a while and getting used to PowerPC assembly (RISC), I noticed that low level CPU virtualization is not possible on PowerPC 970 based Macs. The CPU in documentation (PowerPC 64) seems to support hypervisor mode, but it has been noted that it is not possible due to Open Firmware.
Do all operating systems which are loaded from Open Firmware on PowerPC 970 series Macs load in hypervisor mode, making "nested" virtualization impossible? If this is true, why does Open Firmware load all Operating systems in hypervisor mode? Is this in order to provide a secure layer for communication between the the Operating System and Open Firmware (using firmware for everything except ACPI and memory discovery during boot, which requires a transition into "real-mode", is unsafe in x86?).
Also if the Operating system were using hyper-calls to facilitate a secure transition to firmware based routines, wouldn't this impose a large penalty just as syscalls do?
I'm not privy to Apple's hardware designs, but I've heard that the HV mode (ie., HV=1 in the Machine State Register) was disabled, through hardware, on the CPUs used in the G5 machines.
If this is the case, then it's not up to the system firmware to enable/disable HV mode - it's simply not available.
At the time that these machines were available, other Power hardware designs had a small amount of firmware running in HV=1 mode, and only exposed HV=0 to the kernel. However, the G5 wasn't one of these.
I'm working on a tool which modifies clickonce manifests. I found an ambiguity in the MSDN documents around the clickonce application manifest. It says:
Specifies the processor. The valid values are msil for all processors,
x86 for 32-bit Windows, IA64 for 64-bit Windows, and Itanium for Intel
64-bit Itanium processors.
But yet, this doesn't cover all values. If I compile a clickonce application for a 64-bit only executable, I'll get a manifest with the value amd64. Is this interchangeable with ia64?
amd64 and ia64 are completely different plaforms. They are not interchangeable. The comment from microsoft is indeed misleading.
IA64 refers to Intel's Itanium CPU (developed in partnership with HP) which is 64-bit but which is NOT compatible with the widely used Intel x86 architecture (386,486,Pentium,CORE i3/i5/i7,various AMD,etc). The IA64 CPU uses a completely different instruction set than x86, and the IA64 instruction set implements a design known as VLIW (Very Long Instruction Word).
HP was apparently the main vendor of IA64 systems and they had developed the CPU (with Intel) as a replacement for their own RISC CPU, the HP PA-RISC. HP used Itanium 2 CPUs in their Integrity line of servers, with the high-end model of that line featuring up to 64 Itanium 2 CPUs. HP offered their Unix variant HP-UX as the OS for these IA64 systems, but there was also the option of running a version of Linux for IA64.
Although there were Windows XP and Windows Server releases for Itanium-based systems, I'm not aware of any Windows desktop PC model having much sales success with IA64 CPUs. There were also Linux releases for IA64 including Red Hat.
We can use standard C library routines in standalone micro-controller programming but we cant in linux kernel. my question is, in both cases while they are running on the target hardware both of them dont have access to the libC this explains the "linux kernel" case but what happens when it comes to the standalone application on some micro controller(say MSP430).
Programs running on embedded controllers typically are linked with a (suitably small) version of the standard library. The kernel is not linked to the standard C library, thus it can't be used.