Virtualization on TX2

I was wondering what are the possibilities of virtualizing machines on TX2.

I have mainly 2 topics:

  • Virtualizing a TK1. I would expect better compilation/test/bench times (in which extent virtualized bench times could be interpreted?).
  • Virtualizing a low profile x86 for running WinXP SP3 from a USB3 disk partition. I would just expect to throw away an old noisy PC.

Has anyone experience about virtualizing on TX1/2 platforms or does know this is hopeless ?

This topic is maybe a bit naive. I have to say I have very few experience in virtualization.

For the low profile x86, I’ve found this thread but this gives very little hope.

For TK1, I realize that CUDA would probably not be supported, so if it’s just for compiling this is not so interesting.

However, for a simpler way, would it be possible to run TK1 armhf binaries/libraries with something like

sudo dpkg --add-architecture armhf

Is it possible to install these armhf packages in a separate tree ? (using chroot ?)

Furthermore, what would be the cuda execution model if compiled for arch 3.2 but executed on 6.2 ?
Is it possible to limit CUDA cores to a subset, representative of what’s available in TK1 ?
How much is performance related to driver ?
How could I limit available memory to 2 GB (or less) for TK1/armfh code ?

Thanks for any comment. If it’s stupid, saying it will save my time, no problem !

The ARMv8-A 64-bit has the equivalent of 32-bit ARMv7 hard float plus NEON (simply labeled ARMv8 without the “-A”) in compatibility mode. Consider this similar to a desktop CPU having 64-bit x86_64, plus 32-bit i686…x86_64 is the desktop native architecture, i686 is a foreign architecture. Adding armhf on a 64-bit ARMv8-A is exactly analogous to i686 compatibility on a desktop and is perfectly reasonable foreign architecture which the CPU supports.

Beyond that however, there are a lot o desktops which have tested and refined mixing i686 and x86_64. Under ARMv8-A that practice is untested. Under a desktop gcc actually combines 64-bit and 32-bit, under ARMv8-A you’d have to have separate discrete compilers if you wish to compile both architectures natively. To execute you’d need to also add armhf linker and binutils. How well they work together might be an issue or it might “just work”…if you are entertained by the experiment I’d say “go for it”, it’s interesting new grounds many people have wondered about when they think of building kernels natively on the Jetson. In your case it sounds like you just want to run 32-bit armhf and may not need the 32-bit compiler.