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

[Martin Sivak]

> There's one thing here that makes me wonder, Martin, don't you also
> need to know what's the clock offset to be used? Or, if that's
> indifferent for kubevirt ... why? (asking based on the example you
> gave).

Well.. to be honest I never saw it used.. so here I just do not know.
I would say make it part of the db just in case then. I suppose this
will be simple once all the other questions are answered.

Martin

On Mon, Jan 21, 2019 at 8:40 PM Fabiano Fidêncio <fabiano at fidencio.org> wrote:
>
> b
>
> On Mon, Jan 21, 2019 at 8:23 PM Fabiano Fidêncio <fabiano at fidencio.org> wrote:
> >
> > On Mon, Jan 21, 2019 at 4:42 PM Martin Sivak <msivak at redhat.com> wrote:
> > >
> > > Hi,
> > >
> > > Couple of points:
> > > - do we already handle hypervisor and rachitecture differences
> > > elsewhere in libosinfo?
> > > (it might affect RAM sizes as well for
> > > example)
> >
> > Devices are, for example, listed by hypervisors.
> > Resources (as RAM), for example, listed by architecture.
> >
> > Something that deal with both at the same time, no (or at least not
> > that I remember).
> >
> > > - a timer might be supported in more than one hypervisor (your timer
> > > example does not express that)
> >
> > Actually, it does.
> > Each timer definition would have to be added to the hypervisor itself
> > (hypervisors are "platforms" for osinfo-db) and my suggestion is:
> > - Define a timer (in the same way a device is defined);
> > - Add the timer definition to the platform;
> > - Add the timer definition to the OS;
> >
> > > - the tickpolicy setting is not a property of a timer only, but
> > > depends on the guestos as well
> > >
> >
> > Hmm. Right. But it's also hypervisor dependent right?
> > So, the tickpolicy is something that we'd have to properly have mapped
> > what's supported on each hypervisor and then what can be used by each
> > guest OS. Right?
> >
> > > 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>
> > >
> >
> > Although hat's not the way to go (as, in, having a supported-by field)
> > and this is the most tricky part to have set/defined properly.
>
> Argh. -ENOPARSE here, on my own sentence!
> What I meant was:
> That's not the way to go (as, in, having a supported-by field) and
> this is the most tricky part to have set/defined properly and the main
> reason I've started this thread.
>
> There's one thing here that makes me wonder, Martin, don't you also
> need to know what's the clock offset to be used? Or, if that's
> indifferent for kubevirt ... why? (asking based on the example you
> gave).
>
> >
> > Dan, any suggestion here?
> >
> > [snip]
> >
> > Best Regards,
> > --
> > Fabiano Fidêncio
>
>
>
> --
> Fabiano Fidêncio