> 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@xxxxxxxxxxxx> wrote: > > b > > On Mon, Jan 21, 2019 at 8:23 PM Fabiano Fidêncio <fabiano@xxxxxxxxxxxx> wrote: > > > > On Mon, Jan 21, 2019 at 4:42 PM Martin Sivak <msivak@xxxxxxxxxx> 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 _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
