Virtualizing QNX 6.0

... check out QEMU, and also do a google search for "qnx qemu"

I'm not sure how well the QEMU solution would meet the 'real time performance' the OP mentioned. Also QEMU is quite slow since it emulates the processor as well.

Though there are plenty of VM's (Virtual PC, VirtualBox, VMWare), I think it is unlikely one will find a VM that allows guests OS'es to provide hard real time guarantees while running in that VM.

Unfortunately the OP wasn't specific about the real time deadlines that had to be met, or the host OS.

It

You may want to check out the Real-Time Systems Hypervisor. I know that they give direct hardware access to a guest but I am not sure if they allow you to run QNX with GUI or not.

Only I/O is emulated. Programs run natively until they need to do I/O. Drivers are installed into the guest OS in order to provide native performance for I/O as well. It is the same with vmware.

Perhaps use a hypervisor solution such as XEN?

The non-RT OS is the one that should be running in a virtual environment. Putting qnx in a virtual machine on a pig of an operating such as windows would bring the windows lags to guest and host.

Apparently you are talking about a different QEMU than I am, unless you were talking about KQEMU.

I've used QEMU ahd it doesn't do processor virtualization. For the most part the guest OS runs at native speeds espcially after a driver is installed into the guest OS.

Try valgrind if you want to see just what an emulated processor is like. You're lucky if it runs at a twentieth native speed.

VMware Player or VMware Server are available at no charge. VMware Server is ideal for running VMs on a host that may be headless.

mayby QWIN meets your needs:

(Product flyer and white paper are in english)

performance

I've used QEMU (without the KQEMU driver) on a Windows PC, and it did surely did emulate the processor (just like the author of this software claims, check the website).

Which is close to what I experienced with QEMU, much slower than native or VMWare for example.

performance

With the KQEMU driver, the only sane way of using QEMU when both the host and guest OS are X86, QEMU virtualizes, not emulates.

From the QEMU website: When used as a machine emulator, QEMU can run OSes and programs made for one machine (e.g. an ARM board) on a different machine (e.g. your own PC). By using dynamic translation, it achieves very good performances.

When used as a virtualizer, QEMU achieves near native performances by executing the guest code directly on the host CPU. A host driver called the QEMU accelerator (also known as KQEMU) is needed in this case. The virtualizer mode requires that both the host and guest machine use x86 compatible processors.

performance

QEMU without the KQEMU driver is a very handy if you need a VM but don't want to install something on the system and/or don't have administrative privileges. E.g. one can run a (lightweight) Linux distro from a USB stick in a window without rebooting and without changing a single thing to the system.

...

...

VMware Server is free, no? (I've run the QNX desktop GUI [Neutrino?] under VMware and it behaved quite OK even on single-core hardware.)

VirtualBox (now free from Sun) apparently plays nicer with some peripherals (particularly some USB devices) than VMware does. I've just started to play with it and it looks OK.

mlp

On Wed, 23 Jul 2008, Dombo wrote:

|--------------------------------------------------------------------------------| |"> On Tue, 22 Jul 2008 22:07:49 -0500, Jack Klein wrote:| |> > I'm looking for any suggestions, and especially any real experiences, | |> > that anyone cares to offer. | |> | |> > We have a system that includes an x86 box running QNX 6.something. It | |[..] | | | |I'm not sure how well the QEMU solution would meet the 'real time performance' | |the OP mentioned. Also QEMU is quite slow since it emulates the processor as | |well. | | | |Though there are plenty of VM's (Virtual PC, VirtualBox, VMWare), I think it is | |unlikely one will find a VM that allows guests OS'es to provide hard real time | |guarantees while running in that VM. | | | |Unfortunately the OP wasn't specific about the real time deadlines that had to | |be met, or the host OS." | |--------------------------------------------------------------------------------|

I have not used QNX in QEMU, but I have noticed that the throughput of a simulated operating system in QEMU can be impressively high (depending on what is being done) if the host operating system does not need to use virtual memory for the simulation (i.e. if the simulation can be kept within the host computer's main memory). The high throughput is still accompanied by QEMU's high latency however. I was not trying to access any external hardware, which may make this to be a less useful example for Jack.

I do not know why the people Jack mentioned no longer want a perfectly functioning QNX native installation. I used to study with someone whose master's thesis was about a Windows system he developed by porting a QNX application which he did not develop to Windows. Why do people do these things?

On Sun, 27 Jul 2008 12:12:45 +0100, Colin Paul Gloster wrote in comp.realtime:

|--------------------------------------------------------------------------------|

wrote:|

performance' |

is |

time |

to |

|--------------------------------------------------------------------------------|

Since you asked, I will be happy to reply.

Right now, the product (a medical imaging device) must ship with at least two x86 computers. One, the image acquisition computer, runs QNX 6.something. The other, which is the user workstation and interface to the hospital/clinic network, DICOM translator, image processor, archive, etc., runs under Windows XP.

Having two computers instead of one is an expense in and of itself. Beyond this, it is a maintenance headache. Any particular x86 box these days is not available for a great length of time. By the time we are shipping a particular new computer, its end of life is already announced and we are qualifying and validating the next one.

Seeing as how this is a medical device, which is a highly regulated industry by the FDA in the US and corresponding agencies in other countries and regions of the world, the overhead of testing and documenting any change in hardware is quite substantial.

Right now we are continuously validating not one, but two different replacement computers at any give time, for two different sets of operating systems and applications.

If we can successfully run QNX and the application on a VM under XP, there is now only one computer to validate for hardware updates.

The other great savings potential is simply the fact that new x86 hardware (motherboards, BIOS, network cards, etc.) always ship with Windows driver support. It is not always so easy or quick to have or get QNX drivers for the latest, newest hardware.

At least some VM implementations virtualize hardware interfaces such as NIC, serials ports, USB controllers, so they look generic to the guest OS. That can also save some headaches.

If at all possible, you should have XP in the VM. A RTOS in a VM on a pig like XP will have the same lockups that every XP process is prone.

Baring that, why not just have two PC's sitting side by side? How tightly coupled are the operating systems in the final application? How do they interface?

There are (or at least have been) rack mountable boxes available with two separate passive backplanes with separate power supplies. Add just a KVM switch and the system looks just like a "single computer" as the customer wanted. Of course you can run different operating systems or even different processors on the two backplanes.

Paul

I bet they cost a heck of a lot more than two PC's.

Yes, but they'll be stable and avaialable for 10 years.

The industrial computer market is much better behaved, in terms of deployments, than the consumer market.

I'll third (fourth, fifth) the votes to have XP be the virtualized OS underneath something else. There are very probably good reasons the original designers are using QNX, most likely having to do with the fact that it's a real-time system. XP simply can not provide real-time guarantees.

Oh, and it's increasingly hard to get XP, too.

Depending on exactly how Windows-dependent the user interface code is, it could probably be ported to run on QNX.

And, if he buys server-class rather than consumer-class PCs, his "By the time we are shipping a particular new computer, its end of life is already announced and we are qualifying and validating the next one" problem will go away.