RISC OS on hypervisor

Xen has now been ported to the Pi 4B, see The Register.

Will this get us any closer to running Linux and RISC OS on the same device, so we can seamlessly swap between using the strengths of both OS?

@ David

Xen has now been ported to the Pi 4B

Very cool! :)

Few thoughts:

So Xen is a Paravirtualized Hypervisor (or a type 1 if you prefer), that means each guest OS is aware it’s running as a guest and needs modified drivers and some kernel changes to support such a situation. Also, RISC OS may present some challenges in case of “VM context switching” when it’s performing I/O. I’m not trying to say this won’t work… but I think right now KVM (a type 2 hypervisor) is probably an easier approach for Virtualizing RISC OS.

With that said, I think it would be super cool to have XEN support on RISC OS and being able to switch between Linux and RISC OS live on the same system :)

http://www.update.uu.se/~micken/ronetbsd.html

Michael, that’s fantastic. What RK3399 board is it running on?

RockPro64.

I am currently trying to figure out how to best launch NetBSD from riscos.

Wow! That’ll make a great system. Any news related to your Pinebook Pro and RISC OS?

No news on Pinebook Pro. The main difference is the panel. There is also a DWC usb controller. I managed to get dwc working on RK3288 with old version of riscos driver. But it was unstable.

Thank you for the update on the Pinebook…

While neat, that’s not a hypervisor. It’s two separate cores running effectively bare-metal OSes. You can’t do the usual hypervisor things like save and restore snapshots, nor can you run more OSes than cores. Also there’s limited sandboxing that I can see – each OS can tamper with the other if they so desire. The OS is also tied to a specific hardware platform – no moving an image from your Pinebook to your Pi.

I think the main thing to get running on the ARM hypervisor support would be VirtIO drivers for things like storage, network, USB (and display, although maybe a framebuffer is OK for that), and some support for the hypervisor’s interrupt control. That would support the virtual machine model the hypervisor is providing, abstracting away the specifics of whatever platform you happen to be running on.

Hypervisors often have models of specific I/O devices (eg Intel e1000 network cards) but since RISC OS has never run on a traditional PC platform those are probably of limited use – although EHCI/XHCI/AHCI drivers might be. They’re typically lower performance than VirtIO because of having to emulate lots of registers.

On that note, does RISC OS have support for Device Tree at all?

While neat, that’s not a hypervisor.

OFC. I know that.

On that note, does RISC OS have support for Device Tree at all?

Not yet.

@ Michael Grunditz

neat! But why do you want to share keyboard and mouse? I mean wouldn’t it be even cooler to give NetBSD the network port and WiFi chip and then just create a virtual network between NetBSD and RISC OS?

This will require:
- Only write a virtual NIC driver for RISC OS, using shared memory maybe

Benefits:
- Access NetBSD via Nettle
- Use NedBSD for LAN network and WiFi (allowing RISC OS to finally have WiFi)
- Use NetBSD as a physical and logical firewall for Applications on RISC OS (for example WebJames), you could configure fail2ban on NetBSD or NGINX and modsecurity and proxy WebJames via virtual NIC
- Use the other cores to run services, while keep RISC OS core to run user Desktop (a bit like we used to do back in the days of IBM OS/2, using OS/2 as a user desktop etc… and running an MSDOS instance on it to run our BBS)
- Use NetBSD as a local file system again via virtual NIC and using SMB protocol

just my 0.5c

But why do you want to share keyboard and mouse?

To use some UNIX desktop apps as LibreOffice or Firefox?

@ David

To use some UNIX desktop apps as LibreOffice or Firefox?

That actually can be done on RISC OS itself with the virtual NIC driver idea.

- Configure and run sshd with X11 Forwarding on on NetBSD
- port to 32bit the old X11 Server for RISC OS (yes RISC OS has an X11 Server!)
- Run Firefox and/or LibreOffice on NetBSD via ssh console and redirect X11 output to the X11 Server port on RISC OS

This also gives you more integration between NetBSD apps and RISC OS apps and given the virtual NIC can also run jumbo packets it also gives you decent performances.

just my 0.5c

The problem with X11 forwarding is that many apps, Firefox included can’t be used remotely. At least not the Linux version.

Even if it worked you will want a console.it can be with gfx and keyboard driver as I did or a virtual serial port.

@ Michael

The problem with X11 forwarding is that many apps, Firefox included can’t be used remotely. At least not the Linux version.

hummm why is that? I mean right now, in front of my eyes, I have a Linux firefox instance running on a Windows desktop using X11 Forwarding and it’s working fine.

So, is it something related to NetBSD?

In NetBSD you should be able to create a virtual network and use a memory mapped devices (also because I do not believe the RPi supports I/O MMU and if it does it shouldn’t be enabled anyway).

but ok, if you say it doesn’t work then np.

I haven’t tried it in Windows, but between Linux boxes it doesn’t work . I am member in the uni computer club and we have pc.s running as xterminals. Up until recently Firefox worked just fine, but not anymore.

I rest my case.. I can start Firefox and display on the RiscPC.
So it should work.

But the first step is launching BSD from RISC OS.

cool beans @ Michael! :)

and yeah, possibly in the future it may be easier to start RISC OS from a partition after started Linux, in Linux we can isolate some CPU from the OS and reserve 1 for RISC OS…

my 0.5c

and yeah, possibly in the future it may be easier to start RISC OS from a partition after started Linux, in Linux we can isolate some CPU from the OS and reserve 1 for RISC OS…

What I did before was to launch RISC OS on A72 cpu and then from u-boot started NetBSD on A53 which is the boot cpu. That is fine if you can live with hardcoded memory regions and that both systems starts up at boot. However I don’t think u-boot will be part of the loop in the future, so I need to figure another way.

In Linux you can try to isolate certain CPUs from being used by the entire system by using isolcpu= and memmap=2G$0 as a kernel boot parameters it should leave the two lower GB of RAM available to RISC OS (If I remember correctly these are the ones required by RISC OS to initialise correctly), and the specified CPUs unused.

So in theory it could be possible to write a piece of code in RISC OS (obviously booting RISC OS first) in EL3 or even modify the old ARMLinux bootloader (which started from RISC OS) to boot the Linux kernel with the parameters above and also disabling access to keyboard, mouse and obviously GPU.

If the above works then you could write a “configuration file” from RISC OS side to be used to generate the linux kernel boot parameters.

I had no time to experiment and test this, but will give it a try next weekend, however that should be able to boot Linux from RISC OS…

Did you already managed to share the GIC module?

Why oh why isn’t there a pm function on this forum?!

Anyway, if you look at the requirements for starting Linux, irq and mmu off. It was a long time since i looked at linux kernel, but i think it will start at the boot cpu.

Is it really possible to have different mmu maps for each core?

@Paolo,

You can pm me on twitter.

Is it really possible to have different mmu maps for each core?

Yes. Each core has unique instances of the coprocessor registers that are used to configure the MMU. Most of the other coprocessor registers are core-local too.