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

[Daniel P. Berrangé]

On Tue, Jan 22, 2019 at 12:23:54PM +0100, Fabiano Fidêncio 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?

Yeah, I think so.

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