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

[Fabiano Fidêncio]

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