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
_______________________________________________
Libosinfo mailing list
Libosinfo@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libosinfo
