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

[Martin Sivak]

Hi,

Couple of points:
- do we already handle hypervisor and rachitecture differences
elsewhere in libosinfo? (it might affect RAM sizes as well for
example)
- a timer might be supported in more than one hypervisor (your timer
example does not express that)
- the tickpolicy setting is not a property of a timer only, but
depends on the guestos as well

So if your timers (and devices, features in general) support
hypervisor support fields (supported-by-hv="xen,qemu") and/or
architecture support (supported-by-arch="x86_64,i386,ppc") then you
could express timers in the same way as devices and let the guest os
reference the timer device with catchup policy defined:

Example (might not be the best form for XML or the db):

 <timer id="http://qemu.org/timer/hpet">
    <name>hpet</name>
    <arch>x86_64</arch>
    // The same element repeated with disjunct supported-by attributes (matrix)
    <allowed-tickpolicy supported-by-hv="xen"
supported-by-arch="all">catchup,delay</allowed-tickpolicy>
    <allowed-tickpolicy supported-by-hv="kvm"
supported-by-arch="x86_64,ppc">catchup,delay,merge</allowed-tickpolicy>
  </timer>

  <os>
    <timers>
      <timer id="http://qemu.org/timer/hpet" tickpolicy="catchup"
supported-by-hv="xen"/>
      <timer id="http://qemu.org/timer/hpet" tickpolicy="merge"
supported-by-hv="kvm"/>
    </timers>
  </os>


Martin

On Mon, Jan 21, 2019 at 3:22 PM Fabiano Fidêncio <fidencio at redhat.com> 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;
>
> 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