[Libosinfo] RFC: Add clock/timers info in osinfo-db
Martin Sivak
msivak at redhat.com
Tue Jan 22 09:19:48 UTC 2019
> 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?
Yes, I think so.
Martin
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.
>
> Dan, any suggestion here?
>
> [snip]
>
> Best Regards,
> --
> Fabiano Fidêncio
More information about the Libosinfo
mailing list