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

[Daniel P. Berrangé]

On Mon, Jan 21, 2019 at 03:22:06PM +0100, Fabiano Fidêncio wrote:
> 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;

Yeah, this second point is a big concern for me.

The only things that are purely about guest OS  support are

 - Whether the RTC should be synced to UTC vs localtime
 - Whether a particular timer is supported

The tickpolicy is very much hypervisor dependent so I don't think
that really belongs as a setting against the OS.

Unfortunately, without tickpolicy the timers stuff becomes
significantly less useful to apps.

> 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?

It is "xen" - libxl is a libvirt driver name, "xen" is the hypervisor
name.

> - Shall we care about "timezone" or "variable" possible clock offsets?

Neither of those are relevant. timezone is just a way of saying
the guest clock is synced to "localtime", but in a timezone that
is diffferent from what the host OS uses. "variable" is a way
of expressing the fact that the guest OS has adjusted their
clock away from the original sync point.

> - 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?

"hpet" is not a QEMU invention - it is a standard defined for the
x86 architecture, as at the other timers, so using a qemu.org
namespace would be wrong.

> 
> 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.

My concern with the above is that it feels like we are effectively
re-inventing the "profiles" stuff that was previous discussed, but
in a way that only works for timers.

With both this stuff around timers, and the stuff around features,
it feels like we really need the "profiles" concept to deal with
the fact that what we're trying to express is tied to a pair of
(hypervisor, guest os).

Unfortunately we didn't come to an agreement on the profiles
design concept yet.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|