So is the interrupt thing a real HW bug in the RPi CPU or might this be solvable with some setup magic on the VC black box side? And why does isolating one core on the host side suffice, without restricting which cores the guest can run on? He's running the guest SMP enabled in the example posted.
Hmm. Could be the mailbox communication for VPU<->CPU communication timing out? BCM should be able to repro and fix that. They could also be able to make enabling HYP mode less of a hack.
As for the lack of an accessible GIC, the VPU runs ThreadX, which has a software timer infrastructure: no reason I can see they couldn't expose those if they wanted.
Of course, a virtualized Guest will have a performance penalty.
With that phrase I meant that, following this guide, you can make use of the Virtualization Extensions from the Cortex-A7 which powers the Raspberry Pi 2.
This is pretty useful for running multiple isolated services (such as a media server and an ownCloud instance), doing some kernel hacking, or testing a variety of ARMv7 distributions.
The overhead can be very small, but the overhead is besides the point. The point is that it for example allows you to run things in parallel that you otherwise would need to reboot to run. E.g. testing a different OS or distribution.
Noob questions: Can I run Windows like this? Does it enable Qemu support? Can a non ARM OS be emulated in ARM hardware? (Probably not by hardware extensions, right?)
Why not just use containerization instead? it is the best fit for a RB pi in any aspect. Almost no performance penalty and incredible use cases. Imagine having a fast bare OS on it and deploying remotely containers trough tutum web interface. IoT start to make sense now? :)
This ends up really useful if you want to run a different operating system at the same time. It might make it possible to run Windows RT and Linux at the same time on the RPi2 (or as the author is wanting, NetBSD and Linux). This is something that cannot be done by a container system. For practical setups though, you are correct you'll get a better experience with the lower overhead of a container system and likely better support. Being able to work around the hardware issue on the RPi2 though to enable this is something I didn't think was really doable. Congrats to the author, this is a really great development.