kjliew wrote on 2020-10-12, 01:54:
You are just being naive to think that VMX/EPT are still experimental. They have been here for the past 10 years, stable and wid […]
ragefury32 wrote on 2020-10-12, 00:53:
Eh, not all of those x86 SBCs expose Intel vmx/ept instructions to the OS in their firmware. ... not exposed by default on their shipping firmware - its pretty much an experimental, niche feature
You are just being naive to think that VMX/EPT are still experimental. They have been here for the past 10 years, stable and widely deployed. VirtualBox does take advantage of VMX/EPT and runs a hypervisor, so do VMware and QEMU, otherwise they run like craps. Having a firmware option to disable Virtualization Extension does not imply that the technology is immature. The VMENTER/VMEXIT latency issues have largely been resolved when the I/O device realization has the correct implementation. The net result is still significantly faster than any form of emulation based on dynamic recompilers.
ragefury32 wrote on 2020-10-12, 00:53:
...there are already plenty of existing x64 devices (older thin clients) available now at a price cheaper than one of those SBCs that would work right out of the box.
It is not quite the same in using old device vs a modern, contemporary x86 SBC. Especially when VMs are fully capable of taking advantages of 3D acceleration, even the Intel HD 600 GPU core in the these Atoms triumphs over any old thin-clients if they even offer any 3D acceleration. And, these Atoms SBCs operate in the power envelop of 6W, compared to 45W/65W of old thin-clients.
First of all, you are conflating the experimental status of svm/vmx/ept support in those SBCs with the use of the hardware features in general - the technology is mature, but it doesn't mean its support in those SBC hardware are solid. In those SBCs either they run CoreBoot or there is some kind of UEFI firmware preloaded (in this case on the RockPi X: AMI Aptio). The hardware features enabled via the firmware is dependent on what modules were bundled - it can be quite numerous or it could be quite limited.
Even the developers themselves admit that the firmware on the RockPi X is derived from one meant for a tablet and some features will simply not work, i.e. like this person asking about PXE boot off the NIC:
https://forum.radxa.com/t/cant-seem-to-pxe-bo … -working/4571/8
PXE boot has been around for nearly 30 years, and it doesn't work on this SBC. Thats not because the tech is new, it's because of the experimental/hobbyist nature of the device. If it's experimental, don't expect niche features (like hardware virtualization) to work, or even if it's listed in the BIOS, for it to run through QA the same way it was on a commercial/volume production product. AFAIK these SBCs are classified as hobbyist, and if things don't work (or don't work reliably...like I remember some guy on their forum complaining about the Windows GPU drivers crashing on the hardware once in a while)...well, tough nuggets. I remember having to argue with Intel over the crapulent I2C support in their Galileo SBC several years ago - when hanging an imaging sensor can crash your device and there are no firmware fixes from the biggest name in the semiconductor business, it doesn't bode well for hobbyist hardware in general.
Second of all, how much you want to bet that vmenter/vmexit performance improvements in the Core CPUs will percolate over to their consumer Atom cousins? Even if the hardware support is there, Intel also had an albatross around its neck called L1TF. Atom CPUs are said to not be affected, but unless code is rewritten to exclude Atoms, the standard mitigation can cut into vmenter/vmexit performance - especially costly if there are numerous state changes. Once again, why run virt code when normal emulation works, and in the case of using an Atom or an AMD APU to run x86, why run virt at all? That's just good old x86. Hardware is cheap, just throw another core at the job, or throw a more powerful core. There's no guarantee that going virt will result in significant performance improvements or code quality improvements. QEMU-KVM/VMWare Player/Virtualbox are all virt platforms with x86, SB16 and Cirrus logic SVGA support, and frankly, all 3 of them run DOS games worse than DOSBox - either glitchy audio, glitchy video or laggy performance. That's due to the developers implementing "good enough" support, which is not focused on supporting retrogamers.
Third, this SBC is based on the Cherry Trail SoC which uses a GPU derived from the Intel Haswell/Broadwell generation. The UHD600 (which is derived from the Skylake and found in Apollo Lake Atoms or newer, and I should know, I have a Dell Wyse 5070 thin client with a J4105 on a shelf) are only found in bigger ITX machines. The Cherry Trail Intel HD graphics is substantially weaker than the UHD600 - even the Radeon R2E graphics on a 4-6w AMD APU will be able to match or beat it.
Even then, the Bay Trail GPU in my 7 year old Lenovo tablet can run Command & Conquer Red Alert on Full screen just fine in DOSBox, so clearly this has nothing to do with GPU prowess - as far as I know, any integrated GPU from Intel or AMD made after 2011 is more than enough to run apps in DOSbox just fine.
Lastly, just how much power do you think is needed to run a thin client? An HP t530 (with an AMD GX215J with dual excavator cores, a Radeon R2E derived from GCN3 and running on 6-10w TDP - commonly selling for 90 USD on eBay with 4GB of RAM (upgradeable) and 16GB SSD (also upgradeable)) only uses about 15w maxed out. I am pretty sure that the t530 runs on the same performance bracket as the Cherry Trail. The Dell Wyse 5070 (base price 99 USD) with a pair of 16GB DIMMs and a 256GB SSD? About 13w. Hell, the most powerful thin client that I have (The 400 dollar HP t740 with Ryzen embedded V1756B) uses about 23 to 45w, and thats with a pair of 32GB DIMMs, a 40GbE dual port fiber NIC and running multiple VMs in Proxmox, and that's more like a server (it compares well to a Xeon-D 1518). Most embedded AMD SoCs run on 6-15w or less, the most powerful ones are 35-45w, and those numbers are rarely reached. I should also mention that the thin clients that I have can all support SVM or VMX out of the box.
So no. modern thin clients are only on the ~15w range, 10w on normal duties - not quite the 45-65w you are claiming. This isn't quite like the Igel Winnet J+ from 1999 that I have for playing old DOS games. Even that one is about 22-24w unless I pop the Voodoo2 back in.
So once again - Why buy one of these SBCs for doing emulation? They are experimental in nature, aren't all that performant, and there are used, battle tested, ex-enterprise thin clients that are available cheaply that can perform just as well.