riscv-qemu icon indicating copy to clipboard operation
riscv-qemu copied to clipboard

Support for RTC in virt machine

Open davidlt opened this issue 6 years ago • 3 comments

We are currently using openrdate (e.g., rdate -s rdate.directadmin.com) in Fedora stage4 to set clock once the system boots. The time goes out-of-sync, e.g. when you close your laptop lid for the night thus requiring again to run rdate to sync it up.

It would be nice if we would have RTC in virt machine so we could use: -rtc [base=utc|localtime|date][,clock=host|vm][,driftfix=none|slew] see: http://qemu.weilnetz.de/doc/qemu-doc.html

This could help us avoid some simple and stupid issues when clock skew is too high.

davidlt avatar Feb 23 '18 12:02 davidlt

Regarding host suspend, this almost sounds like a Linux bug. If I'm reading the QEMU code right, mtime should be handled correctly across host-system suspends (it calls gettimeofday() with an offset); Linux should be re-reading mtime on timer interrupts instead of relying on timer interrupts to not be coalesced.

Time on boot-up is a different problem. Currently the device tree has a timebase-frequency node for specifying the nominal proper frequency of the RISC-V/SiFive RTC but no indication of its zero point. A decision needs to be made whether the platform RTC should be extended to track time across resets or whether an entirely separate RTC should be added from hw/timer. (@aswaterman : Does SiFive or freechipsproject have a position on extending the RTC?)

sorear avatar Feb 24 '18 02:02 sorear

I haven't thought about it. @palmer-dabbelt have you?

aswaterman avatar Feb 24 '18 02:02 aswaterman

I think there should be a separate RTC entry in the device tree. On the virt board we can just hook this up to a standard device, that way we don't need our own device driver for now. We'll eventually standardize this as part of the platform.

palmer-dabbelt avatar Feb 27 '18 01:02 palmer-dabbelt