Win10 running X86 on ARM


You can "virtualise" anything.
Virtualization is all about isolation and sharing available ressources, it is not about adding ressources that are not physically available. No matter what kind of system layer we're talking about, code is always being executed natively - virtualization only abstracts access to the hardware - otherwise we're talking emulation. Both terms originate from IBM systems from the early 60s, by the way.
 
Virtualization is all about isolation and sharing available ressources, it is not about adding ressources that are not physically available. No matter what kind of system layer we're talking about, code is always being executed natively - virtualization only abstracts access to the hardware - otherwise we're talking emulation. Both terms originate from IBM systems from the early 60s, by the way.
What do you think emulation is? It's creating a virtual machine (cpu, memory, video display etc.) by using the host machine resources.

The first line of wiki says
In computing, virtualization refers to the act of creating a virtual (rather than actual) version of something, including virtual computer hardware platforms, storage devices, and computer network resources
So it's all about creating virtual versions of something (anything)... Even this quote implies this by referring to "computer hardware platforms".
 
Emulation is hardware-assisted simulation, virtualization is hardware-assisted abstraction. An emulated system has no access to the actual hardware, a virtualized system has mediated direct hardware access.

Given your loose definition every single user program running on a desktop OS is a virtual machine by itself, they all run within a virtual address space - artificial address ranges mapped to different physical address ranges through a MMU that's reporting any forbidden memory access outside the defined ranges as a segmentation fault to the OS.
 
Given your loose definition every single user program running on a desktop OS is a virtual machine by itself, they all run within a virtual address space - artificial address ranges mapped to different physical address ranges through a MMU that's reporting any forbidden memory access outside the defined ranges as a segmentation fault to the OS.
Hmmm, not totally sure about that. The address space may be given a different physical address to virtual address, but it's not creating a new virtual resource, just redirecting it. When you talk about paging files for memory, they are referred to as "Virtual Memory" (at least on Windows).
 
To my recollection, virtualisation was around before hypervisors were in common desktop parts, but thesedays the two approaches have become mangled, so I can understand why someone would say the first needs the latter, even if it was probably a marketing trick by the hypervisor makers to conflate the two concepts.

But I don't have a problem with that. Virtualisation always used to be a woolily defined term, differing only from emulation according to exactly at what level it interrupted things at, or some other metric that varied from person to person, so I'm happy for it to take some more concrete and useful meaning these days.
 
but it's not creating a new virtual resource, just redirecting it.
It is, if you use it for more than RAM access. mmap() a file and you create a virtual resource that virtualizes whole disk access patterns through the virtual address space. Virtualception!
 
It is, if you use it for more than RAM access. mmap() a file and you create a virtual resource that virtualizes whole disk access patterns through the virtual address space. Virtualception!
Not really. mmap() doesn't create a virtual resource, all it does is read a file and plonk it's data in memory, then when you unmap it, all the changes get written back. You also don't access the mapped data using the usual fread() functions, you just select the bytes in memory to read/write. I suppose you could say it's create a virtual copy of a file, but if you go back to the wiki line I quoted, that isn't really covered in that definition of "virtualization" (I keep wanting to spell it with an 's', though I don't know if that's "legitimate" or me just being English).

I would say that I would go with "software pretending to be hardware" is virtualization to me, but hypervisors sort of screw that up. So how about "hardware being shown as available, but that isn't physically there". I think this covers me. If you set up a VM with a single core CPU, even if the code runs on a real CPU core, the "single core CPU" known to the VM doesn't really exist. Using TrueCrypt to mount a virtual disk - It shows up as a disk drive, accessed with the usual disk functions, but is driven by software. Paging files because they are virtual memory blocks. An emulator is virtualization of a machine because all of the h/w components are constructed by software
 
Not really. mmap() doesn't create a virtual resource, all it does is read a file and plonk it's data in memory, then when you unmap it, all the changes get written back. You also don't access the mapped data using the usual fread() functions, you just select the bytes in memory to read/write.
It is a lot more versatile than that, and you may as well map files that are way too large to copy them into memory. The file is effectively split into chunks which are a multiple of the page size, those can be loaded on demand simply by leaving their memory pages configured as inaccessable, triggering an interrupt that makes the kernel load the requested page into memory. The kernel may as well decide to drop some pages again to free up memory - on a shared mapping this may actually trigger an update of those parts of the file on disk without calling munmap() or msync(), in contrast to private mappings they are explicitly meant to change the file and therefore only require msync()/munmap() to make sure that there's no data left to be written at a given point.

(I keep wanting to spell it with an 's', though I don't know if that's "legitimate" or me just being English).
My dictionary tells me the British seem to use both spellings, though the 's' one seems to be the preferred one, naturally. I simply prefer the American spelling.

I would say that I would go with "software pretending to be hardware" is virtualization to me, but hypervisors sort of screw that up. So how about "hardware being shown as available, but that isn't physically there". I think this covers me. If you set up a VM with a single core CPU, even if the code runs on a real CPU core, the "single core CPU" known to the VM doesn't really exist. Using TrueCrypt to mount a virtual disk - It shows up as a disk drive, accessed with the usual disk functions, but is driven by software. Paging files because they are virtual memory blocks. An emulator is virtualization of a machine because all of the h/w components are constructed by software
I'd stick with the term "mediated access".

Talking about virtual drives is a bit fuzzy due to the way the OS handles disk accesses within userspace, the representation of a file on disk is already some kind of virtualization - TrueCrypt is acting just like a common filesystem driver, in the case of using it with a file you simply stack one filesystem driver ontop of another one, which is actually doable with other "normal" filesystem drivers as well. A mounted filesystem from a physical disk is not any less virtual than the one representing the content of a virtual disk.

Virtualized non-existent hardware equals being useless in the sense that it can't do anything, it may only influence things by its sole existence. For example, let's say you have a program that wants to output audio but totally refuses to work because the system tells it that it can't find any sound card. In this case a virtualized sound card can make it work without doing anything, you just need to virtualize /dev/null into it, the sound card does not need to behave in a certain way because that part is hidden behind a replaceable driver. On the other hand, DOSBox e.g. needs to fully emulate a sound card because it is not being abstracted though a system API, the program expects the hardware to behave in a certain way, virtualization can only happen if you already have hardware that behaves exactly as required.

Emulation origins from the IBM S/360 series, they were already using techniques similar to the more modern Chinese Loongson MIPS CPU to execute programs created for incompatible predecessor machines by included a little bit more hardware and modified microcode to wire everything up with the already existing function blocks. However, even those would require a special emulation program. Similarly, the Loongson CPU sacrificed 5% of its die space for adding in x86 compatibility, but still only supports a subset that has to be expanded through an emulator as well, even though it may actually achieve 70% of native performance this way by using those hardware-emulated pseudo-native commands. In this context virtualization of the hardware-emulated CPU architecture would only work if it was acting like a fully featured CPU, which is something that apparently has yet to be done in a way that does not involve simply including a full CPU core (Itanium got rather close to that goal, though).
 
Windows is coming to ARM, and it's going to have built-in x86 emulation for legacy apps! Do you know what this means? It means that the Pyra could possibly have Windows installed on an SD card and allow us to boot it to run our Steam games on! :D Not only that, but as I understand it, newer Windows applications built for ARM should be able to run in an ARM version of WinE with greater performance due to not having to emulate the architecture, just the OS instructions. Imagine it: Rocket League on a handheld using 4G connection!

It may be a while before such a thing actually becomes possible, but with the Pyra being upgradable and Windows coming to ARM, I could see it someday replacing my gaming laptop for most of what I play. What do you guys think? Would you like to dual-boot Windows on a Pyra? Or maybe just emulate newer apps?

It's funny; I recently had someone tell me that I was stupid for thinking I could ever play my Steam games on ARM, and then I hear about this. Forgive me if I'm feeling very smug right now.
 
well, you still can't play your steam games on ARM, unless they're compiled for it... only the Windows bits would be compiled for ARM...
 
well, you still can't play your steam games on ARM, unless they're compiled for it... only the Windows bits would be compiled for ARM...
Unless the rumours of a built in x86 emulator, as Kelvin mentioned, are true. That's basically what exagears and qemu do, but with it tied into the OS itself it'd probably be a lot more efficient. Only time will tell if it's sufficiently efficient to be useful.
 
well, you still can't play your steam games on ARM, unless they're compiled for it... only the Windows bits would be compiled for ARM...
Well playing would be a very loose term here it was pretty sluggish, but hey steam games on the OMAP5 even:

 
It also most likely requires what ever ARM based device Microsoft is blessing this magic Version of windows to run on. Since the Pyra has fairly unique hardware it would need a lot of work done to get it to work, I doubt Microsoft would spend the time to make it work on it.
 
Back
Top