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.
graystevens|11 years ago
nodata|11 years ago
voltagex_|11 years ago
fulafel|11 years ago
AlyssaRowan|11 years ago
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.
agwa|11 years ago
mkoryak|11 years ago
Can someone explain this to me? I know almost nothing about virtualization, but isn't it be definition slower than straight up OS install?
sergiolp|11 years ago
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.
detaro|11 years ago
vidarh|11 years ago
teekert|11 years ago
omh|11 years ago
There will apparently be an ARM version of Windows 10 for the pi, but that's a cut down version for internet of things type apps.
You can emulate x86 on ARM with something like QEMU. But the performance wouldn't be good enough for any modern OS.
wukoje|11 years ago
simcop2387|11 years ago
sciurus|11 years ago
kogepathic|11 years ago
sergiolp|11 years ago
Let's hope that'll be enough to bear with the warm, warm hug of Hacker News ;-)
ipedrazas|11 years ago
dijit|11 years ago