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

[Martin Sivak]

> - Revisit Features/Timers after having a clear idea about the Profiles
> work started by Martin Kletzander.
>
> Does that sound like a deal?

Except the workload profiles are trying to solve a different thing
there (application specific needs on top of guest OS).

Pure libOSinfo is about what a guest OS supports and what the
application _independent_ defaults for the guest OS should be. And the
timers are mostly that (at least RHV always used them like that). The
features we want are 100% that and have definitely nothing to do with
workload profiles. Some of that information is architecture dependent
though but libosinfo apparently knows how to handle this aspect
already.

Hypervisor feature support has also nothing to do with workload
profiles and maybe we need a separate database for hypervisor features
:)

For those reasons I would gently ask to keep those discussions
separate as both hypervisor and workload definitions are specific to
integrator, environment and product (downstream RHV has its own qemu
with extra patches for example).

Best regards

Martin Sivak

On Tue, Jan 22, 2019 at 12:24 PM Fabiano Fidêncio <fidencio at redhat.com> wrote:
>
> On Tue, Jan 22, 2019 at 12:14 PM Daniel P. Berrangé <berrange at redhat.com> wrote:
> >
> > 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.
>
> Okay, so we should:
> - Do not review Features series
> - Do not move forward with the Timers series
> - Get back to the Profiles discussion (Fabian, Martin, your feedback
> there is more than appreciated ... it's actually needed!)
> - Revisit Features/Timers after having a clear idea about the Profiles
> work started by Martin Kletzander.
>
> Does that sound like a deal?



> Best Regards,
> --
> Fabiano Fidêncio