[Libosinfo] RFC: Add clock/timers info in osinfo-db

[Fabiano Fidêncio]

People,

I'd like to start a discussion here as this topic is not as simple as
it looks like.

My first idea would be to have something like:
<os>
  <clock offset="utc|localtime">
    <timer name="hyperv|hpet|kvm|pit|rtc|tsc"
tickpolicy="catchup|delay|discard|merge" arch="aarch64|x86_64|..."
supported="true|false"/>
    ...
  </clock>
</os>

But Daniel raised the following points:
- *every* guest OS wants an RTC timer, the only question is whether
its better to have it synced UTC or locatime;
- "tickpolicy" may not actually be portable across hypervisors;

Now, I'm stuck on how to properly represent those and I'd like to have
some feedback on the following suggestion:
- Create a osinfo-db/data/timer/{qemu.org,xen.org,...} and add there
the supported timers for which platform and add the following timers:
hpet, kvmclock, pit, rtc, tsc and hypervclock.

- Once we have those timers added, we'd have to add them to the
specific platforms:
  - According to https://libvirt.org/formatdomain.html, we have the
following list:
    - hpet: libxl, xen, qemu
    - kvmclock: qemu
    - pit: qemu
    - rtc: qemu
    - tsc: libxl
    - hypervclock: qemu (since 1.2.2)

- And, finally, add those to the OSes;

There are still a few questions that I have:
- Do we treat "libxl" as "xen" on osinfo-db side or is "libxl"
something that has to be added to the platforms?
- Shall we care about "timezone" or "variable" possible clock offsets?
- Are the clock offsets something that's portable across the
platforms? Or, IOW, would be good enough to just have the allowed
values as a choice and deal with that in the schema?
- What would be a reasonable representation for the timers? Something like ...
  <timer id="http://qemu.org/timer/hpet">
    <name>hpet</name>
    <arch>x86_64</arch>
    <tickpolicy>catchup</tickpolicy>
  </timer>
  - In case, it's totally wrong, why? What would be a different way to go?

This seems like a *bunch* of work to be done, but if this is the way
to go, well, this will be the path taken.

Best Regards,
-- 
Fabiano Fidêncio