[Qemu-devel] Run Real Time Guest OS?

[Qemu-devel] Run Real Time Guest OS?

[Steve Ellenoff]

Is it possible to run a real time OS under qemu? What changes would need to 
be made?
Can it even be done?

The guest OS I'm trying to run sets the RTC System Timer 0 to a 0.25ms 
interval (~4000Hz)!! The program I'm trying to run on it, expects this time 
to be accurate, and as such, visually the program seems to be 4-5x too slow 
in qemu, which makes sense given that it's delivering only a 1024Hz timer 
irq.

I've noticed in the source code that qemu sets this max value of 1024Hz 
(1ms) for the timer, which from what I understand is a limit of the Linux 
kernel itself, ie, that's the most the kernel can support.

If I was to run qemu in an RT version of linux ( I was considering KURT ), 
or using some other patch to allow for finer granularity of the linux 
timers, what else would need changing in qemu, ie, what timings are expected 
& assumed by qemu currently?

Before I waste any time investing KURT or other avenues more closely, I just 
wanted to get an idea from you guys if this would even be possible. To me it 
seems like it should be pretty easy to do, but then again, I'm still getting 
familiar with qemu's internals.

Thanks for any advice-
Steve

Re: [Qemu-devel] Run Real Time Guest OS?

[Brad Campbell]

Steve Ellenoff wrote:
> Is it possible to run a real time OS under qemu? What changes would need 
> to be made?
> Can it even be done?
> 
> The guest OS I'm trying to run sets the RTC System Timer 0 to a 0.25ms 
> interval (~4000Hz)!! The program I'm trying to run on it, expects this 
> time to be accurate, and as such, visually the program seems to be 4-5x 
> too slow in qemu, which makes sense given that it's delivering only a 
> 1024Hz timer irq.
> 
> I've noticed in the source code that qemu sets this max value of 1024Hz 
> (1ms) for the timer, which from what I understand is a limit of the 
> Linux kernel itself, ie, that's the most the kernel can support.
> 
Not at all.. for a single qemu instance on linux it tries to use the PIT in the rtc, and I've seen 
this run upto 8192hz. Why not crank it up in the qemu source t0 4096 and see what happens. It's not 
going to hurt anything in any case.
You would most certainly want a HZ value of 1000 to try this.

Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: [Qemu-devel] Run Real Time Guest OS?

[Steve Ellenoff]

BRAD YOU ROCK!! LOL..

It works!!!

I'm not sure what you meant by "you would most certainly want a HZ value of 
1000 to try this", but I simply changed the #define to 4096 as you 
suggested, put it on my fastest machine, and it works perfectly! I didn't 
even get the message saying to echo > 1024 (or in this case 4096), it just 
worked!!

DUDE! I owe you a beer! THANK YOU!! :)

So why when I googled - did I see everywhere it talk about linux having a 
1ms max resolution for timers? I can dig up some links if you need me to. 
This is confusing and what led me down the road to thinking I needed RTLinux 
or some other thing. I"m so thrilled not to have to go there! Perhaps linux 
can't guarantee a reliable and consistent frequency for the timer at speeds 
above 1ms, and any one needing 100% reliable timing would need an RT OS? 
Sure seemed pretty rock solid for me when I ran it, though it's a peppy 
machine.

Anyway, your reply really made my day, no, heck it made my last 2 weeks, 
since my project is now nearing completion and is running perfectly so far 
thanks to this tiny change!

It's funny, I had thought to try it myself a few days ago, but was 
discouraged by what I read on google, and never bothered. DOH!

-Steve

>>Not at all.. for a single qemu instance on linux it tries to use the PIT 
>>in the rtc, and I've seen this run upto 8192hz. Why not crank it up in the 
>>qemu source t0 4096 and see what happens. It's not going to hurt anything 
>>in any case.
>>You would most certainly want a HZ value of 1000 to try this.
>>
>>
>>Brad